zsh-users
 help / color / mirror / code / Atom feed
From: Peter Stephenson <p.stephenson@samsung.com>
To: Zsh-Users List <zsh-users@zsh.org>
Subject: Re: Fish-like autosuggestions
Date: Tue, 05 Nov 2013 16:18:58 +0000	[thread overview]
Message-ID: <20131105161858.543037da@pwslap01u.europe.root.pri> (raw)
In-Reply-To: <131105075700.ZM18043@torch.brasslantern.com>

4On Tue, 05 Nov 2013 07:57:00 -0800
Bart Schaefer <schaefer@brasslantern.com> wrote:
> } - I'm only using recusive-edit because I couldn't do asynchronous updates
> } to the zle RBUFFER using 'zle -F'(I started from the 'predict-on' code)
> 
> Hmm; so the trick here is that if you start recursive-edit, then when
> the zle -F handler executes the special parameters from the surrounding
> (original) ZLE context are still defined in the handler?
> 
> I'm pretty sure this is an unintentional side-effect of recursive-edit,
> and now that you've pointed it out we need to decide whether there is
> (a) any reason this shouldn't continue to work, or (b) whether it ought
> to be necessary, i.e., why the handlers can't always have ZLE context.

I don't remember any good reason why zle -F hooks shouldn't be treated
as ZLE hooks rather than just function hooks.  I know the context I had
in mind when I implemented it was outside zle --- I was expecting the
function to invalidate the display and do something outside ZLE in the
way a job notification would --- but that simply says I wasn't thinking
about ZLE context rather than giving any reason.

It would seem natural to replace the callhookfunc() in raw_getbyte()
with a zlecallhook().  However, that's incompatible so it probably needs
augmenting with an additional option to zle -F to indicate the argument
is a ZLE widget rather than a shell function (a ZLE widget is a
different type of object and it would be silly to have two separate
mechanisms for ZLE widget hooks).  That may throw up some new problems
(not sure if terminal state is sane enough to permit editing the line
that deep inside the code for reading characters, for example), but they
ought to be fixable --- particularly if the recursive-edit hack is
basically working.

pws


  reply	other threads:[~2013-11-05 16:29 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-29 17:52 Thiago Padilha
2013-10-30 16:25 ` Bart Schaefer
2013-11-04 19:30   ` Thiago Padilha
2013-11-05 15:57     ` Bart Schaefer
2013-11-05 16:18       ` Peter Stephenson [this message]
2013-11-05 19:46         ` Bart Schaefer
2013-11-05 20:40           ` Bart Schaefer
2013-11-06 20:07             ` Peter Stephenson
2013-11-07  0:04               ` Bart Schaefer
2013-11-07  9:44                 ` Peter Stephenson
2013-11-07 18:07                   ` Thiago Padilha
2013-11-07 18:12                     ` 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=20131105161858.543037da@pwslap01u.europe.root.pri \
    --to=p.stephenson@samsung.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).