RE: PATCH: collist v2.0

["Andrej Borsenkow" <borsenkow.msk@sni.de>]

First of all, yes, this is incredible. It beats any other command line interface
I've seen so far.

>
> Here is an improved version:
>
> - No more highlighting in normal menu completion.

Is it still possible to switch hihglighting on if desired?

> - There is now another hook which is caught by the module which allows
>   one to replace menu-completion with selection by setting the
>   parameter `ZLS_SELECT'. If it is set, you get into menu-selection
>   whenever menucompletion would be used.
>   This is ugly, it should be an option...

This is basically what I thought about last evening. Completion has three
largely independent parts - building list of matches, displaying list and
selecting match. Completion widgets provide hook for the first; as I uderstand,
with complist Sven added hooks to display lists. It is natural to have hook to
select match. I don't think, the parameter is ugly. But I think, it is better
fitted in compconfig/compstate - user defined key to install menu hook.
'compconf menu_handler=menu_select" or like.

>     There is a problem: I had to strcmp() the name of the widget read
>     with strings like `complete-word' to allow this to work with new
>     style completion widgets. This is ugly -- and a good reason to
>     implement local keymaps.

I don't like it. Users are free to redefine key bindings - I can well imagine
somebody, having complete keymap to mimic TED, Pico or anything he likes. And
then suddenly he finds, that he needs completely different keys to navigate in
e.g. menu selection.

This is the second idea - what about additional hook in key dispatcher? In this
way module could have it's private widget table to do the work. The handler
should return indication, if widget was consumed by it and when it decides, it
should exit, it simply removes the handler. Alternatively, module could install
it's own widget table while it's active - but having the function would probably
spare building the whole table. In this way you won't have any (additional)
overhead at all.

I have nothing against additional keys mapped - but if user has mapped key
sequence to backward-char, he probably expects it to work as such in all places?

> - There shouldn't be any flickering any more when moving around in the
>   menu.

There is. Running under dtterm with empty ZLS_COLORS and having large (ca.
screenfull) list. Moving around gives very visible flickering.

> - One problem with the default colours: I've taken the values from the
>   manual, but without setting LS_* my `ls --colour' seems to use
>   different values. Could someone who actually uses coulured lists
>   please check if the default values are correct? (They look very bad.)

At least the color for executables is bad.

/andrej

P.S. Thank you, Sven!