unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Carlos Pita <carlosjosepita@gmail.com>
To: 51575@debbugs.gnu.org
Subject: bug#51575: 28.0.60; Many issues with icomplete-in-buffer
Date: Sun, 7 Nov 2021 20:10:20 -0300	[thread overview]
Message-ID: <CAELgYhcXGqHm-0efMOADmL_rvJzHnYMg-BEY=orRiCej1TzZug@mail.gmail.com> (raw)
In-Reply-To: <CAELgYhfpmjr0YHdx_TV3zHh+rg4fYiaBVLoegqcHGXNKHSaAiA@mail.gmail.com>

> 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





  reply	other threads:[~2021-11-07 23:10 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-02 22:41 bug#51575: 28.0.60; Many issues with icomplete-in-buffer Carlos Pita
2021-11-07 23:10 ` Carlos Pita [this message]
2023-02-27 18:44 ` Juri Linkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAELgYhcXGqHm-0efMOADmL_rvJzHnYMg-BEY=orRiCej1TzZug@mail.gmail.com' \
    --to=carlosjosepita@gmail.com \
    --cc=51575@debbugs.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).