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

[Ergus]

On Sun, Nov 15, 2020 at 10:56:54PM -0500, Stefan Monnier wrote:
> > > > How can I make that emacs find the file automatically? It needs to be
> > > > added in cus-<something>.el right?
> > > What do you mean by "find the file automatically"?
> > Now I have to load the file with -l to be allowed to use the command.
>
> Oh, then you want to put a `;;;###autoload` cookie just above the entry
> point(s).
>
> > 3) If completion-cycle-threshold is a number then candidates are shown,
> > but when start cycling, the <tab> order is independent from the one in
> > *Completions* (this behavior IMO is even worst). Also, there is not
> > feedback between the current candidate and the visible completions list.
>
> Yes, that's the case I find similar.  The differences I can see are:
> - In your code you get to see the other candidates (with
>  `completion-cycle-threshold` the *Completions* is not necessarily
>  shown).
> - In your code, you get to see your selection highlighted in *Completions*.
> - In your code, you have to hit TAB an extra time, whereas with
>  `completion-cycle-threshold` you start cycling as soon as there are
>  few enough candidates.
> - In your code the threshold depends on the size of *Completions* (and
>  the size of the completions themselves?) rather than being a fixed limit.
> - The order of completions is different.
>
> I think it might be a good idea to try and bring those two closer to
> each other.  E.g. when cycling, make sure the *Completions* buffer, if
> shown, displays the choices in the order in which they are cycled, and
> highlight the chosen one.
Yes, I tried that, but the resulting code was ugly because the candidate
in completion-cycle-threshold is taken from completion--do-completion
directly and totally unrelated with the *Completions* buffer
content.

Changing that would require some changes of completion--cycle-threshold
/ completion--do-completion in minibuffer.el... I am not a proficient
lisper to do that :(. I don't want to break the universe there.

> I think the key [pun unintended] difference between the two is the extra
> TAB which lets you interpret it as a request to enter a special mode
> with special bindings to move between the different
> displayed candidates.

This was intentional because I didn't want to change any default
behavior, so I overloaded the tab just when where unused (*Completions*
is shown and all completions are visible).

The use of the selection/scroll with tab is another effort to not change
any default behavior; because tab scrolls *Completions* when they are
too long. So my code was injected with minimal modification because
initially I wanted to discuss to enable this mode by default in the
future (yes, a man can dream ;p).

I find the current behavior intuitive (and removing the extra tab will
make it even simpler) but I prefer to sacrifice that detail if that
increases the probabilities to enable it by default. Almost only new
users use the *Completion* instead of helm, ivy, icomplete or ido; I
want to improve that first impression.

This is something that could be managed with a custom if you prefer. So
requiring the extra tab or not is easy to implement. Limit the
candidates by number may be a bit more tricky and I am not sure it worth
the effort. Simple is better than complicated. But if you think it worth
the effort I could try...
>        Stefan
Ergus