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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 78944 <at> debbugs.gnu.org, dmoncayo <at> gmail.com
Subject: Re: bug#78944: 31.0.50; Minibuffer completion
Date: Sat, 19 Jul 2025 10:03:37 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  78944 <at> debbugs.gnu.org
> 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.

Ping!  How should we make some progress with this issue?

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

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

On Sat, Jul 19, 2025 at 9:03 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> [...]
>
> Ping!  How should we make some progress with this issue?

FWIW: I don't see a good solution for this (minor) issue.  But I'd
like to say that I'd rather not complicate the (already complex) logic
for minibuffer completion.

-- 
Dani Moncayo

Message #26 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: Tue, 22 Jul 2025 16:08:57 -0400

[Message part 1 (text/plain, inline)]

Dani Moncayo [2025-07-19 09:47:31] wrote:

> On Sat, Jul 19, 2025 at 9:03 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
>>
>> [...]
>>
>> Ping!  How should we make some progress with this issue?
>
> FWIW: I don't see a good solution for this (minor) issue.  But I'd
> like to say that I'd rather not complicate the (already complex) logic
> for minibuffer completion.

Maybe the patch below?  It doesn't actually fix the problem, but with
Dani's recipe it adds a message

    Switched from style ‘partial-completion’ back to ‘basic’

at the end of the minibuffer, to try and explain what's going on.


        Stefan

[minibuffer.patch (text/x-diff, inline)]

diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 122459be062..524c4ffe1d1 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -1298,6 +1298,8 @@ completion--styles
         (delete-dups (append (cdr over) (copy-sequence completion-styles)))
        completion-styles)))
 
+(defvar completion--last-style nil)
+
 (defun completion--nth-completion (n string table pred point metadata)
   "Call the Nth method of completion styles."
   ;; We provide special support for quoting/unquoting here because it cannot
@@ -1310,7 +1310,8 @@
   ;; The quote/unquote function needs to come from the completion table (rather
   ;; than from completion-extra-properties) because it may apply only to some
   ;; part of the string (e.g. substitute-in-file-name).
-  (let* ((md (or metadata
+  (pcase-let*
+      ((md (or metadata
                  (completion-metadata (substring string 0 point) table pred)))
          (requote
           (when (and
@@ -1329,7 +1330,7 @@
               (setq point (pop new))
               (cl-assert (<= point (length string)))
               (pop new))))
-         (result-and-style
+       (`(,result . ,style)
           (seq-some
            (lambda (style)
              (let (symbols values)
@@ -1345,18 +1346,26 @@
                                string table pred point)))
                    (and probe (cons probe style))))))
            (completion--styles md)))
-         (adjust-fn (get (cdr result-and-style) 'completion--adjust-metadata))
+       (adjust-fn (get style 'completion--adjust-metadata))
          (adjusted (completion-metadata-get
                     metadata 'completion--adjusted-metadata)))
     (when (and adjust-fn metadata
                ;; Avoid re-applying the same adjustment (bug#74718).
-               (not (memq (cdr result-and-style) adjusted)))
+               (not (memq style adjusted)))
       (setcdr metadata `((completion--adjusted-metadata
-                          ,(cdr result-and-style) . ,adjusted)
+                          ,style . ,adjusted)
                          . ,(cdr (funcall adjust-fn metadata)))))
-    (if requote
-        (funcall requote (car result-and-style) n)
-      (car result-and-style))))
+    (let ((res (if requote (funcall requote result n) result)))
+      (when (and completion--last-style
+                 (not (eq style (car completion--last-style)))
+                 (equal (cadr completion--last-style) string)
+                 (equal (cddr completion--last-style) point))
+        (message "Switched from style `%S' back to `%S'" ;; bug#78944.
+                 (car completion--last-style) style))
+      (setq completion--last-style
+            (when (stringp (car-safe res))
+              (cons style res)))
+      res)))
 
 (defun completion-try-completion (string table pred point &optional metadata)
   "Try to complete STRING using completion table TABLE.

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of
 text editors" <bug-gnu-emacs <at> gnu.org>
Cc: 78944 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, Dani Moncayo <dmoncayo <at> gmail.com>
Subject: Re: bug#78944: 31.0.50; Minibuffer completion
Date: Wed, 23 Jul 2025 00:29:46 +0200

Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs <at> gnu.org> writes:

> Dani Moncayo [2025-07-19 09:47:31] wrote:
>
>> On Sat, Jul 19, 2025 at 9:03 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
>>>
>>> [...]
>>>
>>> Ping!  How should we make some progress with this issue?
>>
>> FWIW: I don't see a good solution for this (minor) issue.  But I'd
>> like to say that I'd rather not complicate the (already complex) logic
>> for minibuffer completion.
>
> Maybe the patch below?  It doesn't actually fix the problem, but with
> Dani's recipe it adds a message
>
>     Switched from style ‘partial-completion’ back to ‘basic’
>
> at the end of the minibuffer, to try and explain what's going on.

Could we please avoid adding side-effects like message printing to the
functions `completion-all-completions`, `completion-try-completion' and
the underlying `completion--nth-completion`? I'd lean to not adding
complications, or side-effects to this API. Messages are better printed
on a higher level, on the level of completion commands. In case the
message is really needed at least guard it behind an option?

Daniel

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: 78944 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Dani Moncayo <dmoncayo <at> gmail.com>
Subject: Re: bug#78944: 31.0.50; Minibuffer completion
Date: Tue, 22 Jul 2025 20:23:08 -0400

>> Maybe the patch below?  It doesn't actually fix the problem, but with
>> Dani's recipe it adds a message
>>
>>     Switched from style ‘partial-completion’ back to ‘basic’
>>
>> at the end of the minibuffer, to try and explain what's going on.
>
> Could we please avoid adding side-effects like message printing to the
> functions `completion-all-completions`, `completion-try-completion' and
> the underlying `completion--nth-completion`?

These are supposed to be "pure", indeed, so I agree it's not ideal.
The information is only available in there and there's no convenient
"place" to stash that info in the return value.

> I'd lean to not adding complications, or side-effects to this API.

You might be right, but I'm not sure yet.

> Messages are better printed on a higher level, on the level of
> completion commands.

Clearly, yes, but I don't know how to do that here.

> In case the message is really needed at least guard it behind
> an option?

Do you have some concrete case where it gets in the way?


        Stefan

Message #38 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: Wed, 23 Jul 2025 09:12:58 +0200

On Tue, Jul 22, 2025 at 10:09 PM Stefan Monnier
<monnier <at> iro.umontreal.ca> wrote:
>
> Dani Moncayo [2025-07-19 09:47:31] wrote:
>
> > On Sat, Jul 19, 2025 at 9:03 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> >>
> >> [...]
> >>
> >> Ping!  How should we make some progress with this issue?
> >
> > FWIW: I don't see a good solution for this (minor) issue.  But I'd
> > like to say that I'd rather not complicate the (already complex) logic
> > for minibuffer completion.
>
> Maybe the patch below?  It doesn't actually fix the problem, but with
> Dani's recipe it adds a message
>
>     Switched from style ‘partial-completion’ back to ‘basic’
>
> at the end of the minibuffer, to try and explain what's going on.

Thanks. I've just tested your patch, and... I'm sorry to say that I
don't like the new behavior.

I see that the message (Switched from style ‘partial-completion’ back
to ‘basic’) appears just after I type the second TAB.  That gives the
user the impression that something (switching back) happened at that
moment (when I typed the second TAB).

But IIUC, the style switching (forth and back) all took place when I
typed the _first_ TAB.  So, I think that, if the user must see some
message, it should be at that moment (first TAB).

--
Dani Moncayo

Message #41 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: Wed, 23 Jul 2025 09:35:15 +0200

On Wed, Jul 23, 2025 at 9:12 AM Dani Moncayo <dmoncayo <at> gmail.com> wrote:
>
> [...]
>
> But IIUC, the style switching (forth and back) all took place when I
> typed the _first_ TAB.  So, I think that, if the user must see some
> message, it should be at that moment (first TAB).

...and I would suggest something like "[Completed using style 'foo']"
(obviously, to show only if the style used was not the first one in
completion-styles).

-- 
Dani Moncayo

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 78944 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Dani Moncayo <dmoncayo <at> gmail.com>
Subject: Re: bug#78944: 31.0.50; Minibuffer completion
Date: Wed, 23 Jul 2025 09:38:41 +0200

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>>> Maybe the patch below?  It doesn't actually fix the problem, but with
>>> Dani's recipe it adds a message
>>>
>>>     Switched from style ‘partial-completion’ back to ‘basic’
>>>
>>> at the end of the minibuffer, to try and explain what's going on.
>>
>> Could we please avoid adding side-effects like message printing to the
>> functions `completion-all-completions`, `completion-try-completion' and
>> the underlying `completion--nth-completion`?
>
> These are supposed to be "pure", indeed, so I agree it's not ideal.
> The information is only available in there and there's no convenient
> "place" to stash that info in the return value.

Some time ago we had discussed an extended API which returns additional
data as part of the return value, which would be an alist. This way,
impure metadata adjustment could be avoided too.

>> I'd lean to not adding complications, or side-effects to this API.
>
> You might be right, but I'm not sure yet.
>
>> Messages are better printed on a higher level, on the level of
>> completion commands.
>
> Clearly, yes, but I don't know how to do that here.

If we are repeatedly hitting the limits of the current API, maybe it is
time to move to an alternative completion backend API which solves the
issues: Extensible return value as alist, generic methods for completion
tables and completion styles, better composition, extensibility for
additional methods like quoting/unquoting, annotations etc which are
part of the metadata right now, ...

>> In case the message is really needed at least guard it behind
>> an option?
>
> Do you have some concrete case where it gets in the way?

I think about places like auto completion where the APIs are called by a
timer or somehow in the back, decoupled from direct user actions. There
are many such uses where purity is assumed and where such a message
rather hurts than helps.

>         Stefan

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

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Daniel Mendler <mail <at> daniel-mendler.de>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 78944 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Dani Moncayo <dmoncayo <at> gmail.com>
Subject: Re: bug#78944: 31.0.50; Minibuffer completion
Date: Wed, 23 Jul 2025 13:51:12 +0300

On 23/07/2025 10:38, Daniel Mendler via Bug reports for GNU Emacs, the 
Swiss army knife of text editors wrote:
>>> In case the message is really needed at least guard it behind
>>> an option?
>> Do you have some concrete case where it gets in the way?
> I think about places like auto completion where the APIs are called by a
> timer or somehow in the back, decoupled from direct user actions. There
> are many such uses where purity is assumed and where such a message
> rather hurts than helps.

The current completion UI could be also showing some info pertaining to 
the current completion, in the echo area.

Or if the above is disabled, eldoc might be using the echo area for its 
thing, also coding-related.

Message #50 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: Wed, 23 Jul 2025 09:45:52 -0400

>> Maybe the patch below?  It doesn't actually fix the problem, but with
>> Dani's recipe it adds a message
>>
>>     Switched from style ‘partial-completion’ back to ‘basic’
>>
>> at the end of the minibuffer, to try and explain what's going on.
>
> Thanks. I've just tested your patch, and... I'm sorry to say that I
> don't like the new behavior.

No need to be sorry about it.

> I see that the message (Switched from style ‘partial-completion’ back
> to ‘basic’) appears just after I type the second TAB.  That gives the
> user the impression that something (switching back) happened at that
> moment (when I typed the second TAB).
>
> But IIUC, the style switching (forth and back) all took place when I
> typed the _first_ TAB.  So, I think that, if the user must see some
> message, it should be at that moment (first TAB).

The "something" happens *between* the two, in a sense.
The intention for the message was to explain the behavior of the second
TAB rather than to warn about some potential upcoming behavior.

All in all, I guess we'll have to live with the current confusing
behavior.  The only "real" solution I can see is a way to control which
completion style to use, in a way that's visible to the user.
E.g. after the first TAB, the completion machinery could detect that the
result of the TAB from `partial-completion` would get captured by
`basic`, so it could annotate the result with something that means "use
`partial-completion`".  There are lots of interesting issues here, e.g.:

- The cost of detecting it (requires re-running the completion
  internally a second time right at the end of
  `completion-try-completion`).
- How to display the "use `partial-completion`" thingy.
- How to control when that "use `partial-completion`" thingy actually
  applies.

Maybe the solution starts with a way for the user to control which style
is used when (I occasionally find myself needing to use
`partial-completion` and finding that `basic` gets in the way, so I add
a few `*`s to force `basic` to fail (which is the closest we have
currently to "control which style is used"), which can be frustrated
when the candidates also have `*` in their names 🙁).


        Stefan

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: 78944 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Dani Moncayo <dmoncayo <at> gmail.com>
Subject: Re: bug#78944: 31.0.50; Minibuffer completion
Date: Wed, 23 Jul 2025 09:47:05 -0400

>>> In case the message is really needed at least guard it behind
>>> an option?
>> Do you have some concrete case where it gets in the way?
> I think about places like auto completion where the APIs are called by a
> timer or somehow in the back, decoupled from direct user actions.  There
> are many such uses where purity is assumed and where such a message
> rather hurts than helps.

Duh, indeed.


        Stefan

Message #56 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: Wed, 23 Jul 2025 17:36:49 +0200

On Wed, Jul 23, 2025 at 3:45 PM Stefan Monnier <monnier <at> iro.umontreal.ca> wrote:
>
> >> Maybe the patch below?  It doesn't actually fix the problem, but with
> >> Dani's recipe it adds a message
> >>
> >>     Switched from style ‘partial-completion’ back to ‘basic’
> >>
> >> at the end of the minibuffer, to try and explain what's going on.
> >
> > Thanks. I've just tested your patch, and... I'm sorry to say that I
> > don't like the new behavior.
>
> No need to be sorry about it.
>
> > I see that the message (Switched from style ‘partial-completion’ back
> > to ‘basic’) appears just after I type the second TAB.  That gives the
> > user the impression that something (switching back) happened at that
> > moment (when I typed the second TAB).
> >
> > But IIUC, the style switching (forth and back) all took place when I
> > typed the _first_ TAB.  So, I think that, if the user must see some
> > message, it should be at that moment (first TAB).
>
> The "something" happens *between* the two, in a sense.
> The intention for the message was to explain the behavior of the second
> TAB rather than to warn about some potential upcoming behavior.

I see.  But I was thinking of another approach: show what completion
style was used after a (successful) completion operation.  (only when
the style was not the first one in completion-styles).

I think it could be a simple way to show the user what's going on.

-- 
Dani Moncayo

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Dani Moncayo <dmoncayo <at> gmail.com>, Stefan Monnier
 <monnier <at> iro.umontreal.ca>
Cc: "78944 <at> debbugs.gnu.org" <78944 <at> debbugs.gnu.org>,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: RE: [External] : bug#78944: 31.0.50; Minibuffer completion
Date: Wed, 23 Jul 2025 20:57:13 +0000

> I see.  But I was thinking of another approach: show what completion
> style was used after a (successful) completion operation.  (only when
> the style was not the first one in completion-styles).

Caveat/apology: I'm _not_ reading this thread.
I just happened to take a look at this message.
___

FWIW, I've said from the beginning that the design
of vanilla Emacs completion, which automatically
goes on to try the next style after previous styles
couldn't match anything, provides no way for a user
to know which style actually matched/completed.

It kinda assumes that your only aim is to complete
as much and as often as possible, whereas you might
be wanting to know which candidates fit which kinds
of matching (which includes knowing when a given
style or set of styles can't match any candidate).

I think this limitation is baked into the design.

Stefan will correct me...

Previous Next

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