Re: Why the widget bound to menuselect isn't called?

[Sebastian Gniazdowski <sgniazdowski@xxxxxxxxx>]

> Is this correct? Because if yes, then it would seem that the existing
> mechanism can be still used, if the fine-grained widgets will be
> provided and the overloading of the widgets will be enabled

I meant: only for the menuselect keymap / complist module, to solve
that particular problem.

On Sat, 13 Jul 2019 at 14:19, Sebastian Gniazdowski
<sgniazdowski@xxxxxxxxx> wrote:
>
> On Sat, 13 Jul 2019 at 10:59, Oliver Kiddle <okiddle@xxxxxxxxxxx> wrote:
> > ...
>
> The docs also say:
>
> "any other zle function  not  listed leaves menu selection and
> executes that function."
>
> so the widget should be apparently still plainly executed.
>
> >       ...
> >    } else if (cmd ==  Th(z_acceptandinfernexthistory) {
> >       /* special meaning code for accept-and-infer-next-history */
> >       ...
> >    } else if ....
>
> It seems to me that the main problem / idea is to replace the above
> check(s) which are keymap-specific to a more general solution, which
> would:
> – allow automatic mapping of an invocation of a widget to a
> $KEYMAP-variant of the widget
> – provide a set of base widgets that are $KEYMAP-specific, so that
> users can use them as the building blocks of custom widgets.
>
> Then:
> – the above check(s) are an entry point to a set of such
> keymap-specific widgets and seem to implement the keymap-specific
> automatic selection of the widgets, however they're a high level
> widgets, not a fine-grained building blocks,
> – because of this lack of fine-grained widgets the designers of the
> code decided to not allow overloading of them.
>
> Is this correct? Because if yes, then it would seem that the existing
> mechanism can be still used, if the fine-grained widgets will be
> provided and the overloading of the widgets will be enabled.
>
> > If you're wondering what it would take to make this work while not
> > breaking exist user's keybindings, the short answer is quite a lot.
> > Primarily, we need to handle keymap specific special meanings some other
> > way:
>
> It could be that it's a matter of a hard work of adding the missing,
> fine-grained widgets like the vi-forward-char in the C code for the
> menuselect keymap. Or, to provide some even more basic widgets and
> implement the proper building-blocks (like the vi-forward-char) in Zsh
> script.
>
> > We could take the concepts embodied in Functions/Zle/keymap+widget and
> > enshrine it in the C code. I'm not sure I entirely like that because
> > you end up with menuselect+forward-char and menuselect+vi-forward-char
> > widgets rather than a single menuselect-next-match. And how do you
> > reassign forward-char to be column-right rather than next-match (we've
> > had user questions in the past about right-cursor moving to the next row
> > from the last column). A user might just rebind l or cursor-right or
> > whatever but a plugin may want to act independently of the actual keys.
> > Perhaps menuselect+forward-char etc could be aliases.
>
> It seems that it is about forwarding the keymap-specific mechanism to
> the Zshell code in an consistent way with the C code. The question is
> is this necessary?
>
> > A more flexible approach might be to allow conditional zle widget
> > aliases. The condition could be zstyle-like encompassing things like
> > whether the region is active, keymap, PS2 active, completion active,
> > lastwidget. Does that sound useful or over-complicated? keymap+widget
> > might be a useful just as a naming convention.
>
> It sounds versatile but like a hard work. It would create a subsystem
> with much degrees of freedom. I'm unsure if it would have many use
> cases. Could you tell some?
>
> > Aside from that new mechanism, there'd be lots of factoring out of
> > special widgets into their own functions and making sure they don't
> > crash the shell if invoked in the wrong context. It'd inevitably also
> > lead to some extra APIs to allow finer control of menu selection such as
> > the example I gave about moving right when already on the last column.
>
> Yes, it seems so, it's like implementing a system with many hooks.
>
> > PS. bindkey -s will work. Does the following do what you wanted with double-accept?
> >
> >   bindkey -M menuselect -s ' ' '^@^M'
> >   bindkey -M menuselect '^@' auto-suffix-remove
>
> It seems to accept the selection, and the widget is still not called:
>     https://asciinema.org/a/sTCAmyZaJosllGGChZKImtJrt
>
> After removing the ^M, it actually does what I need (but with a
> beep..) – accepts an entry without appending a space, however not
> through the widget – I can put a non-existing widget there and the
> behavior is the same.
>
>
>
> --
> Sebastian Gniazdowski
> News: https://twitter.com/ZdharmaI
> IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin
> Blog: http://zdharma.org



-- 
Sebastian Gniazdowski
News: https://twitter.com/ZdharmaI
IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin
Blog: http://zdharma.org