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

[Drew Adams]

FWIW -

> This mode shows the completions buffer..., but then cycles
> there.... But over a visible list of candidates and
> highlighting the current one.

That's exactly what Icicles does, and has done for
a couple of decades now.

And the sort order in *Completions* is the same as
the cycling order.  And you can change the order
any time, on the fly.

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

Of course.

And you can also go directly to candidates, without
cycling.

Cycling is actually a fairly inefficient, unconscious
way to navigate among candidates.  It's handy, but
dumb cycling shouldn't be the only or the main way to
get around.

Progressively narrowing the current set of matches is
much better.  Combine cycling with that: progressive
completion/filtering, matching multiple simple patterns.
Cycling & filtering work hand in hand.

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

Again, like Icicles.
___

https://www.emacswiki.org/emacs/Icicles_-_Cycling_Completions

https://www.emacswiki.org/emacs/Icicles_-_Progressive_Completion