Re: feature/completions-highlight-modifications e3c5b99 3/6: Add completions-highlight-mode initial implementation.

[Juri Linkov <juri@linkov.net>]

> I made some of the changes you suggested, I think the behavior is a bit
> more reliable now.

Thanks.  Please see more comments.

>>The problem is that such TAB cycling is limited only to the case
>>when the whole *Completions* buffer is visible.
>>
> This was as I said intentional. And to change that could be relatively
> easy but I am not 100% we should. Maybe with a custom in the future...

To be able to merge the branch to master, all its features should work
without problems, but the TAB cycling feature is broken by design:
sometimes it scrolls completions window, sometimes moves to next completion.
This behavior is unpredictable to users.

So I suggest first to implement more straightforward features,
and leave such controversial features at the last thing to do.

>>3. commands that dispatch navigation keys from the minibuffer to the
>>   *Completions* buffer: this doesn't cover other navigation keys.
>>
>>Maybe like windmove-default-keybindings defines modifiers,
>>a similar function could set up modifiers for scrolling completions
>>from the minibuffer, then the users could choose whether to use
>>e.g. 'M-' modifier for scrolling completions, or no modifier at all.
>>
> I will try that when have some time.

This could also allow the user to select what keys to dispatch
to the *Completions* buffer.  For example, TAB and S-TAB move
to the next/previous completion in the *Completions* buffer,
so it makes sense to do the same from the minibuffer as well
(optionally).

>>4. the feature of using completions-highlight-overlay often fails to
>>   update highlighting when point is moved in the *Completions* buffer
>>   by other navigation commands.
>>
>>To fix this, it could work like hl-line-mode, but instead of
>>highlighting the whole line, it could highlight only completions.
>>
> I didn't use the post-command-hook before because I didn't know about it
> when I started and then I forgot to fix that. Please give it a try now.

Highlighting completion under point is useful on its own.
It makes sense for the users to enable it separately from other features,
like hl-line-mode is useful on its own.

> Maybe not a custom but a minor mode is better and simpler. It is just to
> divide my current code in two minor modes instead of just one.

hl-line-mode is a mode because it can be useful in any buffer,
but completion highlighting is useful only in the *Completions* buffer,
so it can be a user option.

>>Then completion highlighting would be useful on its own.
>>A new defcustom e.g. 'completion-highlight' (disabled by default)
>>could add a post-command-hook like hl-line-mode does.
>>Then other completion commands could enable this variable locally.
>
> I made this on the beginning, but I didn't want to add more code to
> simple.el...

Adding much more code to simple.el is undesirable indeed, but
for the completion highlighting feature it would take only
~20 lines of code and option/face definition in minibuffer.el.

All the remaining features need own package file indeed.
BTW, the file name completions-highlight.el is too ugly
as a package name.  An example of a good package/mode name is
icomplete.el.  A new package that allows navigation
of completions from the minibuffer could be like icomplete.el
in other regards too: define the mode/keymap in the same way,
use similar options/hooks, etc.