Re: Fish-like autosuggestions

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Nov 4,  5:30pm, Thiago Padilha wrote:
}
} I would also use the following arguments to
} defend the security of the model:

Thanks for the summary; as I said I handn't looked closely.  I was thinking
of the doc for tcp_proxy:

     caution should be taken as there is no security whatsoever and
     this can leave your computer open to the world.  Ideally, it
     should only be used behind a firewall.

} I've been playing with keymap+widget but I'm still deciding whether it is
} the best solution for the following reasons:
} 
} - 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.

} - Sometimes I have to deactivate the autosuggestions feature and
} consequently some of the widget hooks(eg: editing the middle of the line or
} in vi normal mode)

If deactivation is accomplished by changing a key binding, then this will
"just happen" for e.g. vi mode when the vicmd keymap replaces the one
used by recursive-edit.  If it's deactivated another way, keymap+widget
won't help, but won't hurt either.

} With the current issues in mind I have a few more questions:
} 
} - Is it possible to update the zle RBUFFER from outside a widget?

Only with "print -z" which still requires "zle get-line" at some point
later.

} ... is there a way to enter zle's context from a hook set with 'zle -F' ?

I don't think so, but PWS may know better.

} - Can the keymap+widget feature be used outside recursive-edit?

Yes, as long as you created the keymap with "bindkey -N newkeymap main"
after initializing keymap+widget, switching to that keymap will invoke
the widgets whose names are prefixed with the keymap name.  (It won't
work for other keymaps like vicmd without extra effort, nor for any of
the "special" keymaps like menuselect.)

recursive-edit is just a convenient way to semi-automaticall push/pop
keymaps.

} ... if thats the case I can simply switch
} keymaps with 'zle -K [keymap]' whenever I need a set of widget hooks to be
} active right?

Yes.

} - Whats the best way to modify RBUFFER before a completion widget is
} executed? I've tried the comppostfuncs but the RBUFFER variable is
} read-only in that context.

(comppostfuncs would modify the buffer after the completion widget was
executed.)

It might depend on what you're doing to RBUFFER but the only general
way I can think of is to start off with a normal widget and then call
the desired widget from inside it with "zle completion-widget-name".
If you start out in a widget defined with "zle -C" all of the normal
widget variables are already read-only and you can only affect RBUFFER
by changing what gets passed to compadd.