From: Bart Schaefer <schaefer@brasslantern.com>
To: Zsh Users <zsh-users@zsh.org>
Subject: Re: Cannot use LBUFFER+= nor print -zr from zsh/sched call
Date: Tue, 13 Sep 2016 09:55:36 -0700 [thread overview]
Message-ID: <160913095536.ZM29101@torch.brasslantern.com> (raw)
In-Reply-To: <CAKc7PVD93+km9wvqGD-4BXbhwjB=Sex=tyDJvGSD0EqzQ7VXSA@mail.gmail.com>
On Sep 13, 5:44pm, Sebastian Gniazdowski wrote:
} Subject: Re: Cannot use LBUFFER+= nor print -zr from zsh/sched call
}
} The zle-via-widget method works:
} [...]
} Except it doesn't accept the buffer.
Ah. That's because triggering a sched event doesn't actually stop the
input read loop, so the accept-line won't be processed until the next
time there is actual input.
I suspect maybe the problem here is that you're going about this in
the wrong way to begin with. Why is it important that the commands
be fed to ZLE and executed as if typed?
If I understand your desired end state correctly, I'd implement it
more like the following:
__convey_from_somwhere() {
# Reschedule ourself ...
sched -o +2 __convey_from_somwhere
# Setup ...
local commands
__get_commands_from_somewhere
# Ok, now we have the commands to run. We want them recorded
# in the history as if they were user input, so first do that.
print -S "$commands"
# Now just run them. This assumes we're running from "sched -o"
# (see above) which will handle saving/restoring ZLE state for
# us in case any of these commands interact with the terminal.
eval "${(j.;.)commands"
}
next prev parent reply other threads:[~2016-09-13 17:17 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-11 9:28 Sebastian Gniazdowski
2016-09-11 10:35 ` Sebastian Gniazdowski
2016-09-12 1:13 ` Bart Schaefer
2016-09-12 15:06 ` Bart Schaefer
2016-09-12 15:24 ` Sebastian Gniazdowski
2016-09-12 17:34 ` Bart Schaefer
2016-09-13 15:44 ` Sebastian Gniazdowski
2016-09-13 16:55 ` Bart Schaefer [this message]
2016-09-13 17:29 ` Sebastian Gniazdowski
2016-09-14 1:47 ` Bart Schaefer
2016-09-14 5:13 ` Sebastian Gniazdowski
2016-09-12 0:58 ` Bart Schaefer
2016-09-12 8:49 ` Peter Stephenson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=160913095536.ZM29101@torch.brasslantern.com \
--to=schaefer@brasslantern.com \
--cc=zsh-users@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).