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

[Sebastian Gniazdowski <sgniazdowski@xxxxxxxxx>]

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