GNU bug report logs - #78944
31.0.50; Minibuffer completion

Previous Next

To reply to this bug, email your comments to 78944 AT debbugs.gnu.org.

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

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

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: bug-gnu-emacs <bug-gnu-emacs <at> gnu.org>
Subject: 31.0.50; Minibuffer completion
Date: Wed, 2 Jul 2025 19:41:30 +0200

Starting from 'emacs -Q', type this:
  M-x a u - f i - m o <TAB>

When I do it here, the minibuffer text completes to 'auto-fil-mode'
and the cursor goes just after the 'l'.

But, if I type '?' at that point, I see that 'auto-fill-mode' is the
only completion alternative available.  And '<TAB>' picks it as
expected.

So, why didn't the initial <TAB> pick the only possible completion alternative?

-- 
Dani Moncayo

In GNU Emacs 31.0.50 (build 44, x86_64-pc-linux-gnu, GTK+ Version
 3.24.41, cairo version 1.18.0) of 2025-07-02 built on C11-Q8YAKWONJX0
Repository revision: f48c283e885bbc5feee0804bc12f1cb633249316
Repository branch: master
Windowing system distributor 'Microsoft Corporation', version 11.0.12010000
System Description: Ubuntu 24.04.2 LTS

Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG
LIBSELINUX LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG SECCOMP SOUND
THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE XIM XINERAMA
XINPUT2 XPM XRANDR GTK3 ZLIB

Important settings:
  value of $LANG: C.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  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
  minibuffer-regexp-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug lisp-mnt message mailcap yank-media puny
dired dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg
rfc6068 epg-config gnus-util text-property-search time-date subr-x
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils rmc iso-transl tooltip cconv eldoc paren
electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/x-win x-win term/common-win x-dnd touch-screen 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 nadvice seq simple cl-generic
indonesian philippine 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 abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify
dynamic-setting system-font-setting font-render-setting cairo gtk
x-toolkit xinput2 x multi-tty move-toolbar make-network-process
tty-child-frames emacs)

Memory information:
((conses 16 39832 9463) (symbols 48 5465 0) (strings 32 12884 1934)
 (string-bytes 1 311242) (vectors 16 9587)
 (vector-slots 8 114318 3303) (floats 8 22 2) (intervals 56 243 1)
 (buffers 1064 11))

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dani Moncayo <dmoncayo <at> gmail.com>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 78944 <at> debbugs.gnu.org
Subject: Re: bug#78944: 31.0.50; Minibuffer completion
Date: Wed, 02 Jul 2025 22:12:09 +0300

> From: Dani Moncayo <dmoncayo <at> gmail.com>
> Date: Wed, 2 Jul 2025 19:41:30 +0200
> 
> Starting from 'emacs -Q', type this:
>   M-x a u - f i - m o <TAB>
> 
> When I do it here, the minibuffer text completes to 'auto-fil-mode'
> and the cursor goes just after the 'l'.
> 
> But, if I type '?' at that point, I see that 'auto-fill-mode' is the
> only completion alternative available.  And '<TAB>' picks it as
> expected.
> 
> So, why didn't the initial <TAB> pick the only possible completion alternative?

Stefan, any ideas?

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 78944 <at> debbugs.gnu.org, Dani Moncayo <dmoncayo <at> gmail.com>
Subject: Re: bug#78944: 31.0.50; Minibuffer completion
Date: Wed, 02 Jul 2025 16:15:50 -0400

>> Starting from 'emacs -Q', type this:
>>   M-x a u - f i - m o <TAB>
>> 
>> When I do it here, the minibuffer text completes to 'auto-fil-mode'
>> and the cursor goes just after the 'l'.
>> 
>> But, if I type '?' at that point, I see that 'auto-fill-mode' is the
>> only completion alternative available.  And '<TAB>' picks it as
>> expected.
>> 
>> So, why didn't the initial <TAB> pick the only possible completion alternative?

Because, between the two don't use the same completion style.

From `au-fi-mo[]`, the `basic` completion style finds no match, so we
fallback on the `partial-completion` style which finds 2 matches
(`auto-fill-mode` and `auto-image-file-mode`).

From `auto-fil[]-mode`, OTOH, the `basic` completion style does find
a match (`auto-fill-mode`), so we don't fallback on
`partial-completion`.

If you were looking for `auto-fill-mode`, this misfeature of the
`completion-styles` system is harmless (tho silly), but if you were
looking for `auto-image-file-mode` it can be a lot more annoying.
It's been with us since Emacs-24 so in practice it doesn't seem to be
too often problematic, but ... yeah ...

That's the best way I could find to satisfy the requirement from Richard
that prefix completion should work as before while at the same time
satisfying my requirement that `partial-completion` be enabled by default.


        Stefan

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

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 78944 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#78944: 31.0.50; Minibuffer completion
Date: Thu, 3 Jul 2025 11:48:30 +0200

On Wed, Jul 2, 2025 at 10:15 PM Stefan Monnier <monnier <at> iro.umontreal.ca> wrote:
>
> >> So, why didn't the initial <TAB> pick the only possible completion alternative?
>
> Because, between the two don't use the same completion style.

OK, I understand.

I'm not sure if/how this behavior could be improved.  Perhaps in the
second <TAB> the completion style should still be the same as the one
used before.

Anyway, I'll let you decide.

Thanks.

-- 
Dani Moncayo

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: 78944 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#78944: 31.0.50; Minibuffer completion
Date: Thu, 03 Jul 2025 17:04:15 -0400

Dani Moncayo [2025-07-03 11:48:30] wrote:
> On Wed, Jul 2, 2025 at 10:15 PM Stefan Monnier <monnier <at> iro.umontreal.ca> wrote:
>> >> So, why didn't the initial <TAB> pick the only possible completion alternative?
>> Because, between the two don't use the same completion style.
> OK, I understand.
> I'm not sure if/how this behavior could be improved.  Perhaps in the
> second <TAB> the completion style should still be the same as the one
> used before.

Yeah, there's probably some way to do that, but it's not completely
clear how (e.g. should we still stick to the "last style" if other
commands were issued between the two completion operations?  If so,
which ones should "reset" the styles and which ones shouldn't?).

Maybe a very targeted approach that records the
`completion-try-completion` output (together with the style used), and
then forces the use of the same style when presented with the same input
(i.e. same string and same point position) as the last.

But having different behavior for the same completion input depending on
"how we got there" could be a bit confusing as well.
So maybe instead of forcing the use of the last style when provided with
the same input as the last output and the style is *not* the same as
last time (i.e. in the case that confused you), we could emit a message
saying "switched completion style <FOO> => <BAR>", which could have
saved you the trip to this bug report?

Another option would be to expose the "current style" in the UI
(e.g. with commands to change which style is used).
I think Drew's Icicles takes this approach.


        Stefan

Previous Next

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