Re: Fish-like autosuggestions

[Peter Stephenson <p.w.stephenson@ntlworld.com>]

On Tue, 05 Nov 2013 12:40:00 -0800
Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Nov 5, 11:46am, Bart Schaefer wrote:
> }
> } ... a single predefined widget name that is called at that point ...
> } 
> } Hmm, the doc doesn't actually explain what the return value from a -F
> } handler means to the surrounding code.  There should probably be some
> } sort of return-code-based protocol to indicate whether handling should
> } proceed, which makes me lean away from the "instead" option but still
> } doesn't resolve before/after for me.

It doesn't mean anything: it doesn't make sense for a function
listening for one file descriptor to cause aborting of a function or
widget associated with a different descriptor.  I'd suggest simply we
have either a widget or a normal function for each descriptor and the
problem goes away.  It doesn't make sense to process input from the file
descriptor twice so assigning two processor entities should just be an
error.

> A bit more examination leads me to feel that running the zle -F handler
> first, and then skipping the widget ("zle-tcp-handler" ?) if the -F
> function returns nonzero, is probably the most sensible way to go, both
> for backward compatibility and because it's harder to interpret the
> "failure" of a widget.

You'll have to associate a widget with a file descriptor, so it'll need
to have a specific name --- we could use magic names like
zle-tcp-handler-<fd>, but that's a bit messy and doesn't make clear the
competition between reading the fd this way and the original way.  We
can't just use a generic widget because we don't know what file
descriptors we're listening on.  Listing file descriptors separately
from defining a widget loses both functionality and coherence --- if you
have multiple file descriptors there's no reason to suppose you want to
call the same widget for each, indeed there very likely to be doing
completely different tasks.  So I think the easiest thing is just
slightly augment the interface with an option to say the argument names
a widget rather than a function.  This also makes the implementation
easy: we just do something a little bit different based on a flag
associated with each string in the list.

pws