* 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).