zsh-users
 help / color / mirror / code / Atom feed
* Why the widget bound to menuselect isn't called?
@ 2019-07-11 20:55 Sebastian Gniazdowski
  2019-07-12 18:44 ` Sebastian Gniazdowski
  2019-07-13  8:59 ` Oliver Kiddle
  0 siblings, 2 replies; 12+ messages in thread
From: Sebastian Gniazdowski @ 2019-07-11 20:55 UTC (permalink / raw)
  To: Zsh Users

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Why the widget bound to menuselect isn't called?
  2019-07-11 20:55 Why the widget bound to menuselect isn't called? Sebastian Gniazdowski
@ 2019-07-12 18:44 ` Sebastian Gniazdowski
  2019-07-12 19:36   ` Bart Schaefer
  2019-07-13  8:59 ` Oliver Kiddle
  1 sibling, 1 reply; 12+ messages in thread
From: Sebastian Gniazdowski @ 2019-07-12 18:44 UTC (permalink / raw)
  To: Zsh Users

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Why the widget bound to menuselect isn't called?
  2019-07-12 18:44 ` Sebastian Gniazdowski
@ 2019-07-12 19:36   ` Bart Schaefer
  2019-07-13  1:23     ` Sebastian Gniazdowski
  0 siblings, 1 reply; 12+ messages in thread
From: Bart Schaefer @ 2019-07-12 19:36 UTC (permalink / raw)
  To: Sebastian Gniazdowski; +Cc: Zsh Users

Are you sure that the zsh/complist module is loaded before you execute
the bindkey command?

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Why the widget bound to menuselect isn't called?
  2019-07-12 19:36   ` Bart Schaefer
@ 2019-07-13  1:23     ` Sebastian Gniazdowski
  2019-07-13  2:29       ` Ben Klein
  0 siblings, 1 reply; 12+ messages in thread
From: Sebastian Gniazdowski @ 2019-07-13  1:23 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Zsh Users

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Why the widget bound to menuselect isn't called?
  2019-07-13  1:23     ` Sebastian Gniazdowski
@ 2019-07-13  2:29       ` Ben Klein
  0 siblings, 0 replies; 12+ messages in thread
From: Ben Klein @ 2019-07-13  2:29 UTC (permalink / raw)
  To: Sebastian Gniazdowski; +Cc: Bart Schaefer, Zsh Users

[-- 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
>

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Why the widget bound to menuselect isn't called?
  2019-07-11 20:55 Why the widget bound to menuselect isn't called? Sebastian Gniazdowski
  2019-07-12 18:44 ` Sebastian Gniazdowski
@ 2019-07-13  8:59 ` Oliver Kiddle
  2019-07-13 12:19   ` Sebastian Gniazdowski
  1 sibling, 1 reply; 12+ messages in thread
From: Oliver Kiddle @ 2019-07-13  8:59 UTC (permalink / raw)
  To: Sebastian Gniazdowski; +Cc: Zsh Users

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Why the widget bound to menuselect isn't called?
  2019-07-13  8:59 ` Oliver Kiddle
@ 2019-07-13 12:19   ` Sebastian Gniazdowski
  2019-07-13 12:23     ` Sebastian Gniazdowski
                       ` (2 more replies)
  0 siblings, 3 replies; 12+ messages in thread
From: Sebastian Gniazdowski @ 2019-07-13 12:19 UTC (permalink / raw)
  To: Oliver Kiddle; +Cc: Zsh Users

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Why the widget bound to menuselect isn't called?
  2019-07-13 12:19   ` Sebastian Gniazdowski
@ 2019-07-13 12:23     ` Sebastian Gniazdowski
  2019-07-13 16:39     ` Bart Schaefer
  2019-07-14 10:38     ` Oliver Kiddle
  2 siblings, 0 replies; 12+ messages in thread
From: Sebastian Gniazdowski @ 2019-07-13 12:23 UTC (permalink / raw)
  To: Oliver Kiddle; +Cc: Zsh Users

> 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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Why the widget bound to menuselect isn't called?
  2019-07-13 12:19   ` Sebastian Gniazdowski
  2019-07-13 12:23     ` Sebastian Gniazdowski
@ 2019-07-13 16:39     ` Bart Schaefer
  2019-07-13 16:42       ` Bart Schaefer
  2019-07-14 10:38     ` Oliver Kiddle
  2 siblings, 1 reply; 12+ messages in thread
From: Bart Schaefer @ 2019-07-13 16:39 UTC (permalink / raw)
  To: Sebastian Gniazdowski; +Cc: Oliver Kiddle, Zsh Users

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.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Why the widget bound to menuselect isn't called?
  2019-07-13 16:39     ` Bart Schaefer
@ 2019-07-13 16:42       ` Bart Schaefer
  0 siblings, 0 replies; 12+ messages in thread
From: Bart Schaefer @ 2019-07-13 16:42 UTC (permalink / raw)
  To: Sebastian Gniazdowski; +Cc: Oliver Kiddle, Zsh Users

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".

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Why the widget bound to menuselect isn't called?
  2019-07-13 12:19   ` Sebastian Gniazdowski
  2019-07-13 12:23     ` Sebastian Gniazdowski
  2019-07-13 16:39     ` Bart Schaefer
@ 2019-07-14 10:38     ` Oliver Kiddle
  2019-07-14 21:56       ` Sebastian Gniazdowski
  2 siblings, 1 reply; 12+ messages in thread
From: Oliver Kiddle @ 2019-07-14 10:38 UTC (permalink / raw)
  To: Sebastian Gniazdowski; +Cc: Zsh Users

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Why the widget bound to menuselect isn't called?
  2019-07-14 10:38     ` Oliver Kiddle
@ 2019-07-14 21:56       ` Sebastian Gniazdowski
  0 siblings, 0 replies; 12+ messages in thread
From: Sebastian Gniazdowski @ 2019-07-14 21:56 UTC (permalink / raw)
  To: Oliver Kiddle; +Cc: Zsh Users

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2019-07-14 21:57 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-07-11 20:55 Why the widget bound to menuselect isn't called? Sebastian Gniazdowski
2019-07-12 18:44 ` Sebastian Gniazdowski
2019-07-12 19:36   ` Bart Schaefer
2019-07-13  1:23     ` Sebastian Gniazdowski
2019-07-13  2:29       ` Ben Klein
2019-07-13  8:59 ` Oliver Kiddle
2019-07-13 12:19   ` Sebastian Gniazdowski
2019-07-13 12:23     ` Sebastian Gniazdowski
2019-07-13 16:39     ` Bart Schaefer
2019-07-13 16:42       ` Bart Schaefer
2019-07-14 10:38     ` Oliver Kiddle
2019-07-14 21:56       ` Sebastian Gniazdowski

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).