bug#66948: [PATCH] Add Completion Preview mode

[Eli Zaretskii]

> From: Eshel Yaron <me@eshelyaron.com>
> Cc: philipk@posteo.net,  juri@linkov.net,  dmitry@gutov.dev,
>   stefankangas@gmail.com,  66948@debbugs.gnu.org,  joaotavora@gmail.com
> Date: Sat, 11 Nov 2023 13:01:27 +0100
> 
> >> Basically, a single character often has many completion candidates, and
> >> most of them are not what you want.  After three characters, the preview
> >> is much more likely to show you a useful candidate.  So you can think of
> >> this option as an adjustable threshold for how much information we
> >> require the completion backend to have before we consider its
> >> suggestions any good.  I'm open to changing the default value, but I
> >> think that three characters is a very sane default.
> >
> > The advantage of 1 character is that we don't need this defcustom at
> > all, and it is basically up to the user when to type TAB, or even look
> > at the preview.
> 
> One character is not the same as removing this `defcustom`.  Without
> this `defcustom`, i.e. without checking the length of the symbol at
> point, we would try to show the preview even after the user types a
> bunch of space and there is nothing useful to complete at point at all.
> 
> > Alternatively, we could have a defcustom based on a different design:
> > show preview only when there are fewer than N completion candidates,
> > with N being customizable.  That would make much more sense, IMO,
> > since it replaces a largely "mechanical" limitation with one that is
> > meaningful for users.
> 
> That would indeed be a nice solution, but it has a fatal flaw, sadly.
> Computing the set of completion candidates is a costly operation,
> especially with backends such as LSP, so we don't want to do that after
> each command.

This seems to be an argument in favor of the timer-based design I
suggested.  But if you aren't inclined to do that, I guess we can
install the feature as it is designed now.

> >> > The underline face is not universally supported, so this defface
> >> > should have fallbacks.
> >>
> >> The `underline` face in faces.el has `:underline t` in the fallback
> >> clause too, so I figured that should be alright, no?
> >
> > If you are okay with seeing no effect at all when the terminal doesn't
> > support the underline attribute, then yes.  But I thought we want this
> > face to stand out no matter what, don't we?
> 
> That's okay IMO, the underline just differentiates between when you have
> a single candidate and when you have multiple candidates.  I don't think
> that's that crucial, but if you can suggest a universally supported
> fallback I'd be glad to add it, of course.

How about some color (foreground or background)?