GNU bug report logs - #51575
28.0.60; Many issues with icomplete-in-buffer

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 51575 in the body.
You can then email your comments to 51575 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Carlos Pita <carlosjosepita <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.60; Many issues with icomplete-in-buffer
Date: Tue, 2 Nov 2021 19:41:06 -0300

Hi all,

I would like to use fido-mode in completion in-region / at-point
contexts. I realized there is a icomplete-in-buffer flag that is
intended to do that, at least for icomplete. So I started emacs with:

    (setq icomplete-in-buffer t)
    (icomplete-mode 1)


But the behavior is erratic to say the best. Say I'm in *scratch* and
want to autocomplete some symbol:

1. Doing M-<tab> once shows the icomplete menu, doing it again replaces
the *entire* buffer contents with just the selection.

2. Sometimes only the icomplete menu is shown, sometimes the traditional
*Completions* buffer is shown at the same time.

3. Pressing Enter doesn't select the candidate but inserts Enter.

4. If I enable fido-mode it disables and re-enables icomplete-mode but
leaves the icomplete completion-in-region-mode-hook uninstalled,
disregarding icomplete-in-buffer.

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. The current
implementation wants to show the menu at point, this probably makes it
more complex, but simply showing the standard minibuffer icomplete
interface at the bottom would be a lot (like for example selectrum
does).

Best regards
--
Carlos







In GNU Emacs 28.0.60 (build 1, x86_64-apple-darwin20.6.0, NS
appkit-2022.60 Version 11.6 (Build 20G165))
 of 2021-11-02 built on Carloss-MacBook-Pro.local
Windowing system distributor 'Apple', version 10.3.2022
System Description:  macOS 11.6

Configured using:
 'configure --disable-dependency-tracking --disable-silent-rules
 --enable-locallisppath=/usr/local/share/emacs/site-lisp
 --infodir=/usr/local/Cellar/emacs-plus <at> 28/28.0.50/share/info/emacs
 --prefix=/usr/local/Cellar/emacs-plus <at> 28/28.0.50 --with-xml2
 --with-gnutls --without-dbus --with-imagemagick --with-modules
 --with-rsvg --with-ns --disable-ns-self-contained'

Configured features:
ACL GIF GLIB GMP GNUTLS IMAGEMAGICK JPEG JSON LCMS2 LIBXML2 MODULES
NOTIFY KQUEUE NS PDUMPER PNG RSVG THREADS TIFF TOOLKIT_SCROLL_BARS XIM
ZLIB

Important settings:
  value of $LC_ALL: en_AR.UTF-8
  value of $LC_CTYPE: UTF-8
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  icomplete-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg rfc6068 epg-config gnus-util rmail
rmail-loaddefs text-property-search time-date mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils vc-git
diff-mode vc-dispatcher icomplete info easy-mmode package browse-url url
url-proxy url-privacy url-expand url-methods url-history url-cookie
url-domsuf url-util mailcap url-handlers url-parse auth-source cl-seq
eieio eieio-core cl-macs eieio-loaddefs password-cache json subr-x map
url-vars seq byte-opt gv bytecomp byte-compile cconv cl-loaddefs cl-lib
iso-transl tooltip eldoc paren electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode mwheel term/ns-win ns-win ucs-normalize
mule-util term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button
loaddefs faces cus-face macroexp files window text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads kqueue cocoa ns lcms2
multi-tty make-network-process emacs)

Memory information:
((conses 16 68619 7911)
 (symbols 48 8282 1)
 (strings 32 25724 1866)
 (string-bytes 1 825669)
 (vectors 16 16218)
 (vector-slots 8 218902 10078)
 (floats 8 30 29)
 (intervals 56 347 450)
 (buffers 992 13))

Message #8 received at 51575 <at> debbugs.gnu.org (full text, mbox):

From: Carlos Pita <carlosjosepita <at> gmail.com>
To: 51575 <at> debbugs.gnu.org
Subject: Re: 28.0.60; Many issues with icomplete-in-buffer
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

Message #11 received at 51575 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Carlos Pita <carlosjosepita <at> gmail.com>
Cc: 51575 <at> debbugs.gnu.org
Subject: Re: bug#51575: 28.0.60; Many issues with icomplete-in-buffer
Date: Mon, 27 Feb 2023 20:44:23 +0200

close 51575 30.0.50
thanks

> I would like to use fido-mode in completion in-region / at-point
> contexts. I realized there is a icomplete-in-buffer flag that is
> intended to do that, at least for icomplete. So I started emacs with:
>
>     (setq icomplete-in-buffer t)
>     (icomplete-mode 1)
>
> But the behavior is erratic to say the best. Say I'm in *scratch* and
> want to autocomplete some symbol:
>
> 1. Doing M-<tab> once shows the icomplete menu, doing it again replaces
> the *entire* buffer contents with just the selection.
>
> 2. Sometimes only the icomplete menu is shown, sometimes the traditional
> *Completions* buffer is shown at the same time.
>
> 3. Pressing Enter doesn't select the candidate but inserts Enter.
>
> 4. If I enable fido-mode it disables and re-enables icomplete-mode but
> leaves the icomplete completion-in-region-mode-hook uninstalled,
> disregarding icomplete-in-buffer.
>
> 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. The current
> implementation wants to show the menu at point, this probably makes it
> more complex, but simply showing the standard minibuffer icomplete
> interface at the bottom would be a lot (like for example selectrum
> does).

Thanks for the bug report.  This is fixed now in Emacs 30
for icomplete-mode and fido-mode.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.