Re: Fish-like autosuggestions

[Peter Stephenson <p.stephenson@xxxxxxxxxxx>]

4On Tue, 05 Nov 2013 07:57:00 -0800
Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> 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