#compdef -k menu-select glitch in 3.1.9

#compdef -k menu-select glitch in 3.1.9

[Bart Schaefer]

Remember that function I have that starts with `#compdef -k menu-select ...'?

The zsh/complist module is getting loaded when compinit reads that file,
so that much is working right; but I don't get menu-select behavior when I
invoke the widget.

If I explicitly invoke `zle -C _widget .menu-select _widget' then I do get
menu-select behavior, but for some reason it doesn't work at compinit time.

One other oddity ... before installing 3.1.9 I was using

    #compdef -k menu-complete _widget
    compadd -Q these are some strings
    MENUSELECT=0
    compstate[insert]=menu

With that configuration, every time I exit from menu-selection I get a beep.
With `zle -C _widget .menu-select _widget' I can exit from menu-selection
without getting a beep.  Why the difference?

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: #compdef -k menu-select glitch in 3.1.9

[Bart Schaefer]

On Jun 6,  4:56am, Bart Schaefer wrote:
} Subject: #compdef -k menu-select glitch in 3.1.9
}
} If I explicitly invoke `zle -C _widget .menu-select _widget' then I do get
} menu-select behavior, but for some reason it doesn't work at compinit time.

I found out what's happening: this is partly pilot error on my part, and
partly bad behavior from compinit.

I have two files in my $fpath both named _widget with different #compdef
tags.  compinit processes both of them, in $fpath order, which means that
the #compdef that wins doesn't match the function that gets autoloaded.  I
expected it to only process the one that would actually be autoloaded.

Should we stick a `(( $+functions[$_i_file] )) && continue' or equivalent
into the `for _i_file in ...' loop in compinit?

The other puzzler, with the beeping, still remains.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: #compdef -k menu-select glitch in 3.1.9

[Sven Wischnowsky]

Bart Schaefer wrote:

> On Jun 6,  4:56am, Bart Schaefer wrote:
> } Subject: #compdef -k menu-select glitch in 3.1.9
> }
> } If I explicitly invoke `zle -C _widget .menu-select _widget' then I do get
> } menu-select behavior, but for some reason it doesn't work at compinit time.
> 
> I found out what's happening: this is partly pilot error on my part, and
> partly bad behavior from compinit.
> 
> I have two files in my $fpath both named _widget with different #compdef
> tags.  compinit processes both of them, in $fpath order, which means that
> the #compdef that wins doesn't match the function that gets autoloaded.  I
> expected it to only process the one that would actually be autoloaded.
> 
> Should we stick a `(( $+functions[$_i_file] )) && continue' or equivalent
> into the `for _i_file in ...' loop in compinit?

Or make compinit tell the user about such things and add an option to
make it be quiet (that reminds me of the security checks you suggested 
for loading the completion system; I got no reply to my suggested
patch in 11440).

> The other puzzler, with the beeping, still remains.

That's because menu-select always returns zero, whereas the other
completion widgets return 1 when listing and LISTBEEP is set. Hm, is
it `correct' to make menu-select beep, too? (But that seems a bit
silly, because it always lists, kind of.) I don't have any opinion
here since I don't let it beep at me at all... what do you want to
have? 


Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: #compdef -k menu-select glitch in 3.1.9

[Bart Schaefer]

On Jun 6, 11:48am, Sven Wischnowsky wrote:
} Subject: Re: #compdef -k menu-select glitch in 3.1.9
}
} Bart Schaefer wrote:
} 
} > Should we stick a `(( $+functions[$_i_file] )) && continue' or equivalent
} > into the `for _i_file in ...' loop in compinit?
} 
} Or make compinit tell the user about such things and add an option to
} make it be quiet

That won't do it for me, as I want to have both versions of the function
around.  It should get the right one.

} (that reminds me of the security checks you suggested 
} for loading the completion system; I got no reply to my suggested
} patch in 11440).

Oh, I'm sorry, I thought I had replied.

11440 is the right idea, but I think the test should be for directories
or files that are writable by anyone other than root or the current user.
That means files not owned by the root or the current user fail, as do
files in any group or world writable directory, or in any directory not
owned by root or by the current user.

Then it needs three possibilities for how to treat failure of the tests:

(1) Ask whether to use the completion system.
(2) Silently ignore all directories and files that fail.
(3) Silently accept all directories and files in $fpath.
 
} > The other puzzler, with the beeping, still remains.
} 
} That's because menu-select always returns zero, whereas the other
} completion widgets return 1 when listing and LISTBEEP is set.

But it isn't listing any more at the time of the beep!  I get the beep
when I *exit* from menu selection with a choice, not when I *enter* menu
selection (which would make more sense from the listbeep standpoint).

} Hm, is it `correct' to make menu-select beep, too?

No.

} I don't have any opinion here since I don't let it beep at me at
} all... what do you want to have?

I don't believe menu selection should be considered a listing for the
purposes of listbeep, no matter how you got there; but if it is going to
be, then it ought to beep before and not after.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net