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

[Ergus]

Hi Juri:

Thanks for your time ;)

On Thu, Nov 19, 2020 at 09:45:04AM +0200, Juri Linkov wrote:
> Thanks.  Please see more comments.
>
>
> 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.
I agree. The current tab design is IMO broken by itself but that's not
something I intended to change. In any case the arrow keys are there in
a more consistent way to move... and as we know, there will be never an
agreement on this. So it is better if we find a way to set that
unilaterally to what we think is better and add a custom to disable
it.... More extensions, better alternatives and complains will come out
with the time whatever we do.
> 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).
I understand the idea, but IMO this is pointless. Because M-* or S-* is
not better than just pageup + whatever. I don't find the zsh behavior
confusing an that was my pattern from the beginning. I am worried
because adding more and more bindings (even with a prefix) may

a) Conflict with existing bindings/default current behavior

b) Lead some useless complex combinations like C-M-someting (that does
not work in the terminal very often BTW)

c) conflict with some frequently user-defined bindings. For example
S-arrow now is used to select the region and M-arrow to backward word

Maybe we should look more how zsh behaves... and try to mimic that as
much as possible. Because it is already pretty consisten
> 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.
>
> 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.
Yes, but this actually works as a hook, so we need to add/remove the
command to/from post-command-hook. That's easier and cleaner with a mode
(or a toggle-something command) than with a custom right?. (please,
remember I don't know the deep lisp secrets, so maybe there is actually
a better way)
> 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.
Indeed. I already did that on the beginning, but then I moved it
out. Actually If I can choose it will be better if all the *Completions*
stuff are moved to their own file... But that's a task for a good
developer, not me ;p. There is actuallu the completion.el I am not sure
what's there.

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

I agree, but we have display-fill-column, display-line-numbers... In any
case I don't care the name at all; so I will just ask here for names,
and when the war ends I just obey the winner orders.