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

[Ergus]

Hi Stefan:

On Sun, Nov 15, 2020 at 06:32:08PM -0500, Stefan Monnier wrote:
> > > Please write a description that can be understood by someone who doesn't
> > > know Zsh (or Helm or Ivy or ...).
> > Done!
>
> Much better, thanks.
>
> > Maybe it needs some comments in the manual/NEWS too? If so, where?
>
> I haven't looked at it enough to know, yet, sorry.
>
> > Please check if it needs anything else to be merged into master.  I am
> > reusing the highlight face... but maybe the package needs its own face
> > for the overlay?
>
> Sorry haven't looked at the code yet.
:(

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

> BTW, this new feature reminds me of completion-cycle-threshold.
More or less is the same basic functionality for tabs, but with a lot of
steroids.

1) When completion-cycle-threshold is nil (the default completion) tab
functionality ends when the *Completions* is visible. After that tab
does nothing else unless there are too many candidates and the list
needs to be scrolled.

2) On the other hand when completion-cycle-threshold is t the
completions buffer is never shown. So the completion system behaves more
like vim (ugh), the next completion is not easily predictable. And, of
course, the user can't know how many tabs will need to reach what he
wants.

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.

-----------------

This mode shows the completions buffer (like when
completion-cycle-threshold is nil), but then cycles there (like when
completion-cycle-threshold is non-nil). But over a visible list of
candidates and highlighting the current one.

Once cycling started it is easy to know what will be the next <tab>
candidate or how many tabs (or arrows) are needed to get to a
candidate. It is also possible to go to the candidate down, up, or the
previous one (left) if you accidentally passed it.

Another advantage is that the cursor (point) stays in the same
mini-buffer place after completion, so, in case the list is too long and
you want to reduce it (or a wrong letter was inserted); you only need to
type another letter(backspace) and tab again (like in bash or zsh or the
default completion engine to get a new list).

Finally the mode only changes the default completion behavior once the
completions are visible and another tab is pressed (Where by default Tab
did nothing before).

Hope this helps.
>        Stefan
BTW:

1) completion-cycle-threshold t: is somehow equivalent to bash:

bind "TAB:menu-complete"
bind "set show-all-if-ambiguous on"

2) completion-cycle-threshold nil: is somehow similar to default bash
completion. (tab shows the list and wait more letters)

3) This mode mimics zle from zsh. It is impossible to have this behavior
in bash because readline can't give this. zsh team needed to create zle
to have it.

There are known limitations like that some users will like the
candidates bellow the prompt and not over or have everything in the same
window, or C-g should hide completions instead of exiting the
mini-buffer... But adding them may be too invasive or collide with the
default behavior and may add some worthless complexity.

Best, Ergus.