Re: Inline completion preview

[Eshel Yaron <me@eshelyaron.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Eshel Yaron <me@eshelyaron.com>
>> Cc: emacs-devel@gnu.org
>> Date: Thu, 26 Oct 2023 21:39:16 +0200
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> > I wish people would work on adding to Emacs some a GUI infrastructure
>> > for showing such completion candidates like other IDEs do, instead of
>> > once again using overlays with after-string properties.
>>
>> I'm not sure I know enough about the benefits of other approaches, what
>> do you envision?
>
> Did you see how other IDEs implement this display?  That's what I
> mean.

I've used this feature in other editors (e.g. VS Code), but I didn't
dive into the implementation, if that's what you mean.  Of course some
IDEs are not open source so gaining such insights into their
implementation is non-trivial :(

>> > The result of using overlay strings is simply not visually appealing,
>>
>> It doesn't seem to me very different from what I see in other editors,
>> but I guess that's a matter of taste.
>
> Then maybe you should describe the use case in more details, because
> this could be a misunderstanding of sorts.  What are the use case(s)
> where the feature you propose would be useful?

The use case is this: you're editing some code, maybe it's a language
you're not extremely proficient with, and you want your editor (Emacs)
to give you suggestions for code that it would make some sense to write.
Completion preview does that by showing you a completion candidate you
can insert, and displaying it as if you've already inserted it, so you
know exactly what it'll look like (you get a preview).  As you are
typing, Emacs updates the suggestion based on your keystrokes.  If you
couple that with a good completion backend, you get useful suggestions
with a very low friction interface.

>> Sorry, that might have not been clear enough, I wrote:
>>
>>     ISTM that the best approach is a simple library that uses only
>>     `completion-at-point` as a backend, because `completion-at-point` is
>>     already extensible enough to support a variety of completion
>>     backends.
>
> This is an argument from the implementation POV, it basically says
> "let's do it because we can".  The question I asked is different: why
> do we need to invent something new when we seem to already have
> similar functionalities that are widely used?

To be clear, I think adding Company to core Emacs instead of my
completion-preview.el or some such is a perfectly viable solution.  I do
think there are some considerations in favor of my proposal (see below),
and some against, naturally.

> A response I expected would explain why those existing packages cannot
> support the desired feature, or are too heavy for such a simple
> feature, or have some other issues when used for this functionality.

Alright, let me review the alternatives:

- `fancy-dabbrev` is probably insufficient because it only works with
  `dabbrev`.  It's also only available on MELPA which might make it
  harder to incorporate in core.

- `corfu-candidate-overlay` relies on `corfu`, and I've had a small
  issue while testing it that sometimes the overlay lingered after point
  moved, but otherwise I think that if `corfu` would be in core this
  package would be a fine solution.  MELPA-only as well.

- `mono-complete` is quite nice IMO, but it's a larger package that
  comes with multiple backends besides `completion-at-point`, including
  a bespoke python program that generates word predictions, and I think
  that something simpler may be more appropriate.  It is also only on MELPA.

- `company` is great, battle tested, fully featured, and on GNU ELPA.
  It's an interesting option to explore IMO.  It does add an extra level
  of complexity with its multiple frontends and backends scheme, that
  I'm not sure is needed in core.

- `completion-preview` only provides a completion preview frontend, and
  only targets `completion-at-point` as a backend, so it benefits from
  tight integration.  Obviously, it is does not provide all of the
  features that `company` provides, and it isn't very well tested.  OTOH
  it's less than 150 lines of code, so we could actually even add it to
  completion.el instead of having a separate library.



Best,

Eshel