RE: PATCH: collist v2.0

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Andrej Borsenkow wrote:

> > Here is an improved version:
> >
> > - No more highlighting in normal menu completion.
> 
> Is it still possible to switch hihglighting on if desired?

Hm, no. I could add it again, using a different ZLS_COLOURS-capability 
-- should I? (Didn't someone say that this is irritating?)

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

The hooks I added are C-hooks, not visible to shell code. So
supporting a configuration key for this is a completely different
thing, and completely independent.

It would be easy to add something like

  if [[ -n "$compconfig[menu_select]" ]]; then
    ZLS_SELECT=''
  else
    unset ZLS_SELECT
  fi

to _main_complete, or, probably better

  [[ -n "$compconfig[menu_select]" ]] && ZLS_SELECT=''

in a completer named _menu_select or something.

> >     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 why I said that it's a good reason for local keymaps. In this
case I would create a local keymap by copying the one currently being
used and change some of the keys that should be expected to work
(cursor, return, tab, probably undo). We could avoid that copying if
we were able to define sparse keymaps and use them as override-maps
(i.e. if one of the keys defined in the sparse map is used, you get
the definition from it, otherwise you get the definition of the normal 
keymap). With that creating and installing such a local keymap would
be very cheap.

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

Functions like menu-select (or execute-named-command and so on) do the 
key-dispatch directly, they don't use the global key-loop. In these
cases I really think that local keymaps are the easier way.
Nonetheless the key-loop is one of the places where I would like to
have hooks for modules (remember me saying that there are other places 
where we might want to add hooks?).
And another thing: when we started this programming widget discussion
you suggested a command that reads something from the minibuffer
(which, of course, we don't have either, we only have a statusline
which is used by some functions to display something prompt-like --
functions with their own command loops of course). I would like to
have that, too, but I would prefer to bring `zle' and friends to a
state where we can implement that in shell code. That should give us
more freedom for configuration, I think (and it would also be a good
test for the widget-programming stuff).

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

See above.

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

Grunz. Yes, you're right, but unless someone modifies collistmatches() 
so that it only redisplays the old and the new line where the
highlighted match was/is, that can't be helped (and such a change is
not entirely trivial). I was referring to xterm which is faster.


Bye
 Sven


--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx