Re: menu-select interactive mode

[Mikael Magnusson <mikachu@xxxxxxxxx>]

On 10 April 2011 16:48, Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> On Apr 9, 10:58pm, Mikael Magnusson wrote:
> }
> } On 9 April 2011 22:12, Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> }
> } > } Additionally, when you do the second one, ie set both select and
> } > } interactive, the menu-select widget does invoke interactiveness, so my
> } > } guess is the code simply checks the style instead of also checking
> } > } which widget invoked it.
> } >
> } > That's sort of the right diagnosis.  There are several possible ways
> } > to "fix" this if it's wrong, and I don't know which one is correct.
> } >
> } I might be getting myself in a confused state by this point, but
> } neither of these seemed to do it for me with just setting 'menu
> } interactive' and using menu-complete, I did check that I zmodload
> } complist first too.

Okay, when I try it now it seems the first patch does work, so I must
have been confused yesterday. (A curious difference between this and
using my menu-select-interactive widget: pressing ctrl-c removes the
list with my widget but not with menu-select, subsequent presses of
menu-select then just cycle through the matches instead of going into
menu-selection again, but let's leave this for later :).)

> Using menu-complete or using menu-select?  Note that the test looks
> explicitly for the menu-select widget by name.  Should it instead be
> looking for menu-* as a pattern?

Intuitively I feel like the very place that checks if the 'menu' style
contains 'select' should also check if the widget is called
'menu-select'. menu-complete doesn't imply selection, does it? (I
admit all these slightly different terms are a bit confusing to me.)
This is not to say that that would be better than your patch, I
obviously don't know what I'm talking about.

> } btw, both MENUSELECT and MENUMODE seem to "leak" out into the main
> } shell environment, is that necessary to keep the state consistent
> } during completion?
>
> It's because the complist module needs both of them set (and MENUSCROLL
> if you have that style) and on any given entry to _main_complete it's
> not known whether they were previously set by either the user or by
> _main_complete itself maintaining state for the next pass.  That is,
> _main_complete gets menu selection started but then _main_complete
> returns to the top level.  The menu-select internals are then in
> control and need those variables to remain set.  To clean them up
> properly we'd need a hook on menu-select exiting.
>
> Hmm, nowadays it might be possible to do it with a zle-line-init hook.
> That didn't exist when this code in _main_complete was written.
>
> } btw#2, this whole interactive feature is very under-advertised, I've
> } used zsh since 2003 and even have commit access, and I never heard
> } about it before today.
>
> Zsh doesn't really have a marketing department. :-)  Volunteers?
>
> There are still some bugs in the interactive mode.  Starting from the
> "ls" above, type "c":
>
> torch% ls c
> interactive: config.[]
> config.h           config.log         config.modules.sh
> config.h-xx        config.modules     config.status*
>
> Now press TAB:
>
> torch% ls config.
> interactive: config.[]
> config.h           config.log         config.modules.sh
> config.h-xx        config.modules     config.status*
>
> Then type "l":
>
> torch% ls config.l
> interactive: config.log[]
> config.log
>
> Then press ENTER to accept the one-and-only match:
>
> torch% ls config.log l
>
> Finally type ENTER again:
>
> torch% ls config.logl
> ls: config.logl: No such file or directory

Yeah, I noticed a couple of things too, if you complete some levels of
directories and accept, then undo it all, you're left with the bits
you typed manually, only the completion-inserted parts are removed.
You can also not use more complex patterns than a simple * or ?, as
soon as you type a non-matching glob it drops you back into the main
shell. Even if you manage to type a ( or | it will just start
completing commands or worse instead of files :). I don't know if this
is a bug or not, the documentation doesn't really say what you can
type in it. Ie if i have files foo and bar and type (foo|bar) into the
interactive menu completion it will tell me no matches, then when I
press enter to accept my command it does match the files.

-- 
Mikael Magnusson