Subject: bug#51575: 28.0.60; Many issues with icomplete-in-buffer

From: Carlos Pita <[email-masked]>
Date: Sun, 7 Nov 2021 20:10:20 -0300

> Maybe this is a legacy option that should be made obsolete, but it's a
> pity that vanilla emacs provides so many alternatives for
> completing-read but none for completion-at-point.
> [...] simply showing the standard minibuffer icomplete
> interface at the bottom would be a lot (like for example selectrum
> does).

I've learned some new facts that may be relevant to this:

- The consult package [1] provides this functionality for any
completing-read solution, including icomplete/fido (and also vertico
[2] and selectrum [3], although selectrum also provides a builtin
alternative).

- IDE-like packages that use LSP-servers to get completions are
popular these days and their completions are based on the contents of
the buffer (I guess the server works at the file level), so any
solution that moves the edition to the minibuffer will fail to update
the buffer and therefore won't play well with the LSP-server.

So in-minibuffer is simple to implement and there are external
implementations that are compatible with icomplete, but it's not
LSP-friendly.

OTOH, emacs includes what AFAICS is a broken attempt to implement
something like in-buffer icomplete, which perhaps will be harder to
get right. External packages that do similar stuff are:

- corfu [4]: minimalistic, restricted to core protocols as everything
in the new "completion stack" (vertico, consult, etc), uses child
frames and fallbacks to the default completion on TUI.

- company [5]: extends core protocols with its own ones, although
there is a trend to move most backends under the capf (completion at
point) one, uses overlays that are mostly ok but have some rough edges
like inserting gaps into the line number area.

- company-box [6] and company-posframe [7]: different frontends for
company that use child frames instead of overlays.

I'm still not able to assess how far the current implementation is
from being functional, but I believe it's reasonable to keep any
builtin solution simple, even if that means to leave the LSP in-buffer
case to third parties. Next in complexity is a corfu-like
implementation, which is still small and minimalistic. The decision
between child frames (that don't support TUI) and overlays (that are
somewhat of a hack) is a tough call though.

Best regards,
Carlos

---

[1] https://github.com/minad/consult
[2] https://github.com/minad/vertico
[3] https://github.com/raxod502/selectrum
[4] https://github.com/minad/corfu
[5] http://company-mode.github.io/
[6] https://github.com/sebastiencs/company-box
[7] https://github.com/tumashu/company-posframe