Hello, I'm seeing no message in /tmp/reply: function double-accept { echo 1 >> /tmp/reply; } zle -N double-accept bindkey -M menuselect ' ' double-accept Why? -- Sebastian Gniazdowski News: https://twitter.com/ZdharmaI IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin Blog: http://zdharma.org
No hints on this one? On Thu, 11 Jul 2019 at 22:55, Sebastian Gniazdowski <sgniazdowski@gmail.com> wrote: > > Hello, > I'm seeing no message in /tmp/reply: > > function double-accept { echo 1 >> /tmp/reply; } > zle -N double-accept > bindkey -M menuselect ' ' double-accept > > Why? > -- > 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
Are you sure that the zsh/complist module is loaded before you execute the bindkey command?
On Fri, 12 Jul 2019 at 21:36, Bart Schaefer <schaefer@brasslantern.com> wrote: > > Are you sure that the zsh/complist module is loaded before you execute > the bindkey command? Yes, it is, and I've also tried the snippet in the interactive session after issuing the zmodload just to be sure. Doesn't this reproduce for you? -- Sebastian Gniazdowski News: https://twitter.com/ZdharmaI IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin Blog: http://zdharma.org
[-- Attachment #1: Type: text/plain, Size: 1278 bytes --] Welp I can confirm that the modification of the menuselect keymap binds doesn't appear to have any effect. Doesn't matter what key I try to bind to in menuselect, none of them seem to activate. robo-triangulum% bindkey -M menuselect "^A" double-accept "^I" complete-word "^J" accept-line "^M" double-accept "^[OA" up-line-or-history "^[OB" down-line-or-history "^[OC" forward-char "^[OD" backward-char "^[[A" up-line-or-history "^[[B" down-line-or-history "^[[C" forward-char "^[[D" backward-char " " double-accept robo-triangulum% *\Ben Klein* About: https://unhexium.net/about/ Other places online: https://unhexium.net/ll/ Contact me securely: https://keybase.io/robobenklein On Fri, Jul 12, 2019 at 9:24 PM Sebastian Gniazdowski < sgniazdowski@gmail.com> wrote: > On Fri, 12 Jul 2019 at 21:36, Bart Schaefer <schaefer@brasslantern.com> > wrote: > > > > Are you sure that the zsh/complist module is loaded before you execute > > the bindkey command? > > Yes, it is, and I've also tried the snippet in the interactive session > after issuing the zmodload just to be sure. Doesn't this reproduce for > you? > > -- > Sebastian Gniazdowski > News: https://twitter.com/ZdharmaI > IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin > Blog: http://zdharma.org >
Sebastian Gniazdowski wrote:
> function double-accept { echo 1 >> /tmp/reply; }
> zle -N double-accept
> bindkey -M menuselect ' ' double-accept
>
> Why?
Because custom widgets aren't supported by complist and never have been.
In the documentation for the complist module, just before the effect of
the various zle widgets are described, it states:
The following zle functions have special meaning during menu
selection. Note that the following always perform the same
task within the menu selection map and cannot be replaced
by user defined widgets, nor can the set of functions be
extended:
That doesn't really answer your question of "Why?" but this isn't easy
to explain briefly. What follows is more suited to -workers:
It is a feature to give "special meaning" to existing widgets
for something like menu selection. Consider something like
accept-and-infer-next-history: accepting the current selection and
allowing menu selection to continue is conceptually very similar
to accepting a line from history and moving to the next one. So
the special meaning allows whatever key a user configured to
accept-and-infer-next-history to do something similar in menu selection.
Note that the menuselect keymap is a local keymap so only acts to
override bindings in whatever your main keymap is.
complist is implemented as a module so the code for
accept-and-infer-next-history can't check whether menu selection
is active unlike the checks for, e.g. the region being active.
So the complist code does stuff like:
cmd = getkeycmd();
...
if (cmd == TH(z_viinsert)) {
/* enter interactive mode */
...
} else if (cmd == Th(z_acceptandinfernexthistory) {
/* special meaning code for accept-and-infer-next-history */
...
} else if ....
...
} else /* any other widget */
ungetkeycmd();
/* accept selected match */
If you search for getkeycmd() in zle_main.c, you'll see it followed
by a call to execzlefunc().
It isn't just menuselect but also the command, isearch, listscroll
keymaps where this happens. When incremental history was implemented, we
didn't have local keymaps or user defined widgets so the implementation
there was perfectly natural at the time.
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:
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.
We could allow zle widget aliases to be keymap specific. So we'd
predefine the aliases and they could be changed, e.g:
zle -A forward-char -M menuselect menuselect-column-right
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.
Once before when this was vaguely discussed, Bart mentioned emacs minor
modes. Does anyone know how those are implemented underneath?
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.
Oliver
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
On Sat, 13 Jul 2019 at 10:59, Oliver Kiddle <okiddle@yahoo.co.uk> 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
> 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@gmail.com> wrote: > > On Sat, 13 Jul 2019 at 10:59, Oliver Kiddle <okiddle@yahoo.co.uk> 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
On Sat, Jul 13, 2019 at 5:20 AM Sebastian Gniazdowski <sgniazdowski@gmail.com> 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. What you're missing is this bit: Any key that is not defined in this keymap or that is bound to `undefined-key' is looked up in the keymap currently selected. That means you exit the menuselect keymap and return to the "current" keymap before the binding for the keystroke is looked up; it doesn't mean that the function looked up in the menuselect keymap is executed after leaving. > 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 Menuselect is restricted in this way deliberately so that the user can't perform any action that would garble the screen or confuse the cursor placement. The right thing would probably have been to create a new set of widgets specific to menuselect and simply declare that they couldn't be changed, but as a shortcut the most similar existing actions were simply co-opted.
On Sat, Jul 13, 2019 at 9:39 AM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> Any key that is not defined in this keymap or that is bound to
> `undefined-key'
This is definitely ambiguous wording. "Not defined in this keymap"
means "not listed in the description of the keymap that immediately
preceded this text", rather than "not provided some alternate
definition via the bindkey command".
Sebastian Gniazdowski wrote: > 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. Yes. However, there would be further problems like ensuring that non- menu selection widgets abort menu selection and preserve backwards compatibility as far as possible. Providing basic widgets would be the easy (but tedious) part. The automatic mapping is harder because an approach needs to be worked out and designed. > 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. I'm not sure I follow what you're saying. It may have been better if there had been fine-grained widgets to begin with but that alone is not sufficient (either now or at the time of the module's inception). > 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? Consistency with Functions/Zle/keymap+widget isn't necessary. Not breaking backwards compatibility that allows menu selection key bindings to reflect users' normal key bindings is necessary. I was trying to outline some vague ideas on how this might be approached. Oliver
On Sun, 14 Jul 2019 at 12:38, Oliver Kiddle <okiddle@yahoo.co.uk> wrote: > The automatic mapping is harder > because an approach needs to be worked out and designed. > ... > I'm not sure I follow what you're saying. It may have been better if > there had been fine-grained widgets to begin with but that alone is not > sufficient (either now or at the time of the module's inception). I was making a point that the automatic mapping solely for the menuselect case is actually available – despite being probably not at the level of quality and design that we would expect from it – because the complist module does automatically get the calls if they're done on the menuselect keymap. So to solve the particular issue with non-overloadable menuselect widgets what has to be done is to provide the rest of the Zle widgets – to give them meaning in the menuselect keymap, so that there's no risk that user's overloading widget will call something's unimplemented – the Zsh script code isn't a threat here, only the dot- i.e. original zle .widgets are. > > 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? > > Consistency with Functions/Zle/keymap+widget isn't necessary. > Not breaking backwards compatibility that allows menu selection key > bindings to reflect users' normal key bindings is necessary. I was > trying to outline some vague ideas on how this might be approached. I wonder if the enabling of overloading of the menuselect keymap doesn't break the backwards compatibility. The "always leave menu-selection" behavior, for example, will be changed by it. An configuration option, rather preferably zstyle, could be used to guard the compatible behavior (BTW. are zstyles used to influence Zshell at the C level currently?). -- Sebastian Gniazdowski News: https://twitter.com/ZdharmaI IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin Blog: http://zdharma.org