GNU bug report logs - #74616
30.0.92; tmm always displays the *Completions* 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 74616 in the body.
You can then email your comments to 74616 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: Daniel Mendler <mail <at> daniel-mendler.de>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.92; tmm always displays the *Completions* buffer
Date: Sat, 30 Nov 2024 07:42:33 +0100

The `tmm-add-prompt' function of tmm.el automatically displays the
*Completions* buffer by calling `minibuffer-completion-help'. If an
alternative minibuffer completion system like Icomplete or Vertico is
used, the *Completions* buffer is not needed since the candidates are
already displayed in the minibuffer. I propose to either detect these
alternative completion systems (e.g., by checking the value of the
completing-read-function and/or the mode variables) or to provide a new
customization variable `tmm-display-completions' which defaults to t but
can be set to nil to disable the call to `minibuffer-completion-help'. I
am happy to provide a patch for either of these approaches.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: 74616 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#74616: 30.0.92; tmm always displays the *Completions* buffer
Date: Sat, 30 Nov 2024 10:04:48 +0200

> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Date: Sat, 30 Nov 2024 07:42:33 +0100
> From:  Daniel Mendler via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> The `tmm-add-prompt' function of tmm.el automatically displays the
> *Completions* buffer by calling `minibuffer-completion-help'. If an
> alternative minibuffer completion system like Icomplete or Vertico is
> used, the *Completions* buffer is not needed since the candidates are
> already displayed in the minibuffer. I propose to either detect these
> alternative completion systems (e.g., by checking the value of the
> completing-read-function and/or the mode variables) or to provide a new
> customization variable `tmm-display-completions' which defaults to t but
> can be set to nil to disable the call to `minibuffer-completion-help'. I
> am happy to provide a patch for either of these approaches.

I think the automatic detection is a better default behavior, but
maybe we could have a variable (not necessarily a defcustom) for users
who would like to have the old behavior.

Stefan, WDYT?

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 74616 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#74616: 30.0.92; tmm always displays the *Completions* buffer
Date: Sat, 30 Nov 2024 09:12:57 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>
>> Date: Sat, 30 Nov 2024 07:42:33 +0100
>> From:  Daniel Mendler via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>> 
>> The `tmm-add-prompt' function of tmm.el automatically displays the
>> *Completions* buffer by calling `minibuffer-completion-help'. If an
>> alternative minibuffer completion system like Icomplete or Vertico is
>> used, the *Completions* buffer is not needed since the candidates are
>> already displayed in the minibuffer. I propose to either detect these
>> alternative completion systems (e.g., by checking the value of the
>> completing-read-function and/or the mode variables) or to provide a new
>> customization variable `tmm-display-completions' which defaults to t but
>> can be set to nil to disable the call to `minibuffer-completion-help'. I
>> am happy to provide a patch for either of these approaches.
>
> I think the automatic detection is a better default behavior, but
> maybe we could have a variable (not necessarily a defcustom) for users
> who would like to have the old behavior.

See also what I wrote on my ffap bug report. It may make sense to
provide some more general mechanism (auto detection, custom variable,
...) in minibuffer.el which could be used by tmm, ffap and other
packages. For example my GNU ELPA package Jinx faces the same problem -
if default completion is used, `minibuffer-completion-help' should be
called to display the candidates immediately, but not for other
completion UIs.

> Stefan, WDYT?

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Daniel Mendler <mail <at> daniel-mendler.de>, 74616 <at> debbugs.gnu.org
Subject: Re: bug#74616: 30.0.92; tmm always displays the *Completions* buffer
Date: Sat, 30 Nov 2024 13:55:02 -0500

> I think the automatic detection is a better default behavior, but
> maybe we could have a variable (not necessarily a defcustom) for users
> who would like to have the old behavior.
> Stefan, WDYT?

I often use the standard UI and I generally don't like this eagerness to
display *Completions*, so I'd either change the code not to auto-display
the buffer (what I have done locally) or at least offer a variable
for that.

So it seems like the war should have 3 settings: always show, never
show, and "guess" (tho maybe we can skip the "guess" option and let the
other completion UIs set the var to nil).


        Stefan

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Daniel Mendler <mail <at> daniel-mendler.de>, 74616 <at> debbugs.gnu.org,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#74616: 30.0.92; tmm always displays the *Completions* buffer
Date: Sun, 01 Dec 2024 12:00:45 +0800

Hello,

On Sat 30 Nov 2024 at 01:55pm -05, Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote:

> I often use the standard UI and I generally don't like this eagerness to
> display *Completions*, so I'd either change the code not to auto-display
> the buffer (what I have done locally) or at least offer a variable
> for that.

"eagerness to display *Completions*" made me think of this NEWS.30 entry
which is a stopgap compatibility fix that we'd like to improve:

    +++
    ** The "*Completions*" buffer now always accompanies 'icomplete-in-buffer'.
    Previously, it was not consistent whether the "*Completions*" buffer would
    appear when using 'icomplete-in-buffer'.  Now the "*Completions*" buffer
    and Icomplete's in-buffer display of possible completions always
    appear together.  If you would prefer to see only Icomplete's
    in-buffer display, and not the "*Completions*" buffer, you can add this
    to your init file:

        (advice-add 'completion-at-point :after #'minibuffer-hide-completions)

Possibly the resolution of this bug could help there, too.

-- 
Sean Whitton

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: mail <at> daniel-mendler.de, 74616 <at> debbugs.gnu.org
Subject: Re: bug#74616: 30.0.92; tmm always displays the *Completions* buffer
Date: Sat, 07 Dec 2024 14:55:14 +0200

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Daniel Mendler <mail <at> daniel-mendler.de>,  74616 <at> debbugs.gnu.org
> Date: Sat, 30 Nov 2024 13:55:02 -0500
> 
> > I think the automatic detection is a better default behavior, but
> > maybe we could have a variable (not necessarily a defcustom) for users
> > who would like to have the old behavior.
> > Stefan, WDYT?
> 
> I often use the standard UI and I generally don't like this eagerness to
> display *Completions*, so I'd either change the code not to auto-display
> the buffer (what I have done locally) or at least offer a variable
> for that.
> 
> So it seems like the var should have 3 settings: always show, never
> show, and "guess" (tho maybe we can skip the "guess" option and let the
> other completion UIs set the var to nil).

Daniel, would you like to submit the patch with these changes?

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 74616 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#74616: 30.0.92; tmm always displays the *Completions* buffer
Date: Sat, 07 Dec 2024 15:38:14 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
>> Cc: Daniel Mendler <mail <at> daniel-mendler.de>,  74616 <at> debbugs.gnu.org
>> Date: Sat, 30 Nov 2024 13:55:02 -0500
>> 
>> > I think the automatic detection is a better default behavior, but
>> > maybe we could have a variable (not necessarily a defcustom) for users
>> > who would like to have the old behavior.
>> > Stefan, WDYT?
>> 
>> I often use the standard UI and I generally don't like this eagerness to
>> display *Completions*, so I'd either change the code not to auto-display
>> the buffer (what I have done locally) or at least offer a variable
>> for that.
>> 
>> So it seems like the var should have 3 settings: always show, never
>> show, and "guess" (tho maybe we can skip the "guess" option and let the
>> other completion UIs set the var to nil).
>
> Daniel, would you like to submit the patch with these changes?

So is the plan to add a completion metadata `eager-display' such that
completion tables can request immediate display? This completion
metadata can then be overridden by the user via
`completion-category-overrides'. The patch would include changes to tmm,
ffap-menu and imenu (obsoleting `imenu-eager-completion-buffer').

Daniel

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: 74616 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#74616: 30.0.92; tmm always displays the *Completions* buffer
Date: Sun, 08 Dec 2024 09:17:26 +0200

> From: Daniel Mendler <mail <at> daniel-mendler.de>
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>,  74616 <at> debbugs.gnu.org
> Date: Sat, 07 Dec 2024 15:38:14 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> >> Cc: Daniel Mendler <mail <at> daniel-mendler.de>,  74616 <at> debbugs.gnu.org
> >> Date: Sat, 30 Nov 2024 13:55:02 -0500
> >> 
> >> > I think the automatic detection is a better default behavior, but
> >> > maybe we could have a variable (not necessarily a defcustom) for users
> >> > who would like to have the old behavior.
> >> > Stefan, WDYT?
> >> 
> >> I often use the standard UI and I generally don't like this eagerness to
> >> display *Completions*, so I'd either change the code not to auto-display
> >> the buffer (what I have done locally) or at least offer a variable
> >> for that.
> >> 
> >> So it seems like the var should have 3 settings: always show, never
> >> show, and "guess" (tho maybe we can skip the "guess" option and let the
> >> other completion UIs set the var to nil).
> >
> > Daniel, would you like to submit the patch with these changes?
> 
> So is the plan to add a completion metadata `eager-display' such that
> completion tables can request immediate display? This completion
> metadata can then be overridden by the user via
> `completion-category-overrides'. The patch would include changes to tmm,
> ffap-menu and imenu (obsoleting `imenu-eager-completion-buffer').

AFAIU, both Stefan and myself only commented on the more specific
change you suggested originally, not the more general one you
described in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=74616#11

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 74616 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#74616: 30.0.92; tmm always displays the *Completions* buffer
Date: Sun, 08 Dec 2024 08:49:02 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Daniel Mendler <mail <at> daniel-mendler.de>
>> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>,  74616 <at> debbugs.gnu.org
>> Date: Sat, 07 Dec 2024 15:38:14 +0100
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> >> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
>> >> Cc: Daniel Mendler <mail <at> daniel-mendler.de>,  74616 <at> debbugs.gnu.org
>> >> Date: Sat, 30 Nov 2024 13:55:02 -0500
>> >> 
>> >> > I think the automatic detection is a better default behavior, but
>> >> > maybe we could have a variable (not necessarily a defcustom) for users
>> >> > who would like to have the old behavior.
>> >> > Stefan, WDYT?
>> >> 
>> >> I often use the standard UI and I generally don't like this eagerness to
>> >> display *Completions*, so I'd either change the code not to auto-display
>> >> the buffer (what I have done locally) or at least offer a variable
>> >> for that.
>> >> 
>> >> So it seems like the var should have 3 settings: always show, never
>> >> show, and "guess" (tho maybe we can skip the "guess" option and let the
>> >> other completion UIs set the var to nil).
>> >
>> > Daniel, would you like to submit the patch with these changes?
>> 
>> So is the plan to add a completion metadata `eager-display' such that
>> completion tables can request immediate display? This completion
>> metadata can then be overridden by the user via
>> `completion-category-overrides'. The patch would include changes to tmm,
>> ffap-menu and imenu (obsoleting `imenu-eager-completion-buffer').
>
> AFAIU, both Stefan and myself only commented on the more specific
> change you suggested originally, not the more general one you
> described in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=74616#11

Okay, I see. Is there interest in a general solution for all the
scenarios, instead of replicating customization variables multiple
times? Then users like Stefan who don't like the eager display, or
completion UIs would only have to customize a single variable once.

If a customization variable is preferred over the completion metadata,
one could add a `minibuffer-eager-completion-help-function function
to minibuffer.el (please make suggestions for a better name):

(defcustom minibuffer-eager-completion-help-function #'minibuffer-completion-help
  "Can be set to `minibuffer-completion-help' to show the eager display,
to `ignore' to disable the eager display, or to a custom function which
performs auto detection."
  ...)

It would be used like this at the call sites (imenu, ffap, tmm):

(minibuffer-with-setup-hook
    minibuffer-eager-completion-help-function
  (completing-read ...))

Daniel

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 74616 <at> debbugs.gnu.org
Subject: Re: bug#74616: 30.0.92; tmm always displays the *Completions* buffer
Date: Sun, 08 Dec 2024 10:33:53 -0500

> So is the plan to add a completion metadata `eager-display' such that
> completion tables can request immediate display? This completion
> metadata can then be overridden by the user via
> `completion-category-overrides'. The patch would include changes to tmm,
> ffap-menu and imenu (obsoleting `imenu-eager-completion-buffer').

That sounds good, except that in order for
`completion-category-overrides` to work reliably, the `eager-display`
should not be in the metadata but in `completion-category-defaults`.


        Stefan

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 74616 <at> debbugs.gnu.org,
 Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#74616: 30.0.92; tmm always displays the *Completions* buffer
Date: Sun, 08 Dec 2024 20:59:06 +0100

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

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

>> So is the plan to add a completion metadata `eager-display' such that
>> completion tables can request immediate display? This completion
>> metadata can then be overridden by the user via
>> `completion-category-overrides'. The patch would include changes to tmm,
>> ffap-menu and imenu (obsoleting `imenu-eager-completion-buffer').
>
> That sounds good, except that in order for
> `completion-category-overrides` to work reliably, the `eager-display`
> should not be in the metadata but in `completion-category-defaults`.

Okay. Can you please clarify why you assume that overriding isn't
reliably possible if the metadata is specified directly? In
`completion-metadata-get' the `completion-category-defaults' and
`completion-category-overrides' take precedence over the completion
table metadata.

I attached a patch which adds a customization option
`completion-eager-display' and an `eager-display' completion table
metadata. The customization option can be set to nil (never), t (always)
or to auto, which means that the *Completions* buffer will only be shown
if the completion table requests eager display via the `eager-display'
metadata.

I updated ffap.el, tmm.el and imenu.el to take advantage of the new
`eager-display' metadata. I added completion categories where missing
such that overriding the metadata becomes possible. If desired, the
metadata can be moved to `completion-category-defaults' instead.

Daniel

[0001-New-customization-variable-completion-eager-display.patch (text/x-diff, attachment)]

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 74616 <at> debbugs.gnu.org,
 Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#74616: 30.0.92; tmm always displays the *Completions* buffer
Date: Mon, 09 Dec 2024 09:19:44 -0500

> Okay. Can you please clarify why you assume that overriding isn't
> reliably possible if the metadata is specified directly?

Because `completion-category-overrides` works only if there's an
appropriate `category` to use.  If the `eager-display` info comes
straight from the metadata, there's no guarantee that there's
an associated `category` info that can be used.


        Stefan

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 74616 <at> debbugs.gnu.org,
 Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#74616: 30.0.92; tmm always displays the *Completions* buffer
Date: Mon, 09 Dec 2024 15:44:08 +0100

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

>> Okay. Can you please clarify why you assume that overriding isn't
>> reliably possible if the metadata is specified directly?
>
> Because `completion-category-overrides` works only if there's an
> appropriate `category` to use.  If the `eager-display` info comes
> straight from the metadata, there's no guarantee that there's
> an associated `category` info that can be used.

I've added both completion categories and eager-display. Please see the
attached patch. As soon as there is a completion category, overriding
will work. While the completion category is a necessary prerequisite to
support overriding, adding eager-display at either places should do.
Also note the addition of the completion-eager-display defcustom (with
values nil, t, auto), which will make it much easier to turn off eager
display globally.

Daniel

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: 74616 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca, juri <at> linkov.net
Subject: Re: bug#74616: 30.0.92; tmm always displays the *Completions* buffer
Date: Mon, 09 Dec 2024 17:25:53 +0200

> From: Daniel Mendler <mail <at> daniel-mendler.de>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  74616 <at> debbugs.gnu.org,  Juri Linkov
>  <juri <at> linkov.net>
> Date: Mon, 09 Dec 2024 15:44:08 +0100
> 
> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> 
> >> Okay. Can you please clarify why you assume that overriding isn't
> >> reliably possible if the metadata is specified directly?
> >
> > Because `completion-category-overrides` works only if there's an
> > appropriate `category` to use.  If the `eager-display` info comes
> > straight from the metadata, there's no guarantee that there's
> > an associated `category` info that can be used.
> 
> I've added both completion categories and eager-display. Please see the
> attached patch.

ENOPATCH

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 74616 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca, juri <at> linkov.net
Subject: Re: bug#74616: 30.0.92; tmm always displays the *Completions* buffer
Date: Mon, 09 Dec 2024 16:42:23 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Daniel Mendler <mail <at> daniel-mendler.de>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>,  74616 <at> debbugs.gnu.org,  Juri Linkov
>>  <juri <at> linkov.net>
>> Date: Mon, 09 Dec 2024 15:44:08 +0100
>> 
>> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> 
>> >> Okay. Can you please clarify why you assume that overriding isn't
>> >> reliably possible if the metadata is specified directly?
>> >
>> > Because `completion-category-overrides` works only if there's an
>> > appropriate `category` to use.  If the `eager-display` info comes
>> > straight from the metadata, there's no guarantee that there's
>> > an associated `category` info that can be used.
>> 
>> I've added both completion categories and eager-display. Please see the
>> attached patch.
>
> ENOPATCH

https://debbugs.gnu.org/cgi/bugreport.cgi?msg=35;bug=74616

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

From: Juri Linkov <juri <at> linkov.net>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 74616 <at> debbugs.gnu.org,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#74616: 30.0.92; tmm always displays the *Completions* buffer
Date: Mon, 09 Dec 2024 21:03:10 +0200

> I attached a patch which adds a customization option
> `completion-eager-display' and an `eager-display' completion table
> metadata. The customization option can be set to nil (never), t (always)
> or to auto, which means that the *Completions* buffer will only be shown
> if the completion table requests eager display via the `eager-display'
> metadata.
>
> I updated ffap.el, tmm.el and imenu.el to take advantage of the new
> `eager-display' metadata. I added completion categories where missing
> such that overriding the metadata becomes possible. If desired, the
> metadata can be moved to `completion-category-defaults' instead.

Thanks, I tested everything, and it works nicely.

One small detail that could be added later is to extend
the customization type of `completion-category-overrides'
:value-type with `eager-display'.  Since currently
only programmatic use is supported.

Also tried to do:

  (add-to-list 'completion-category-overrides
               '(tmm (eager-display . nil)))

but after typing TAB it pops up the completion buffer
where all functionality is lost.  Is this because
`tmm-add-prompt' is called only for non-nil `eager-display'?

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Juri Linkov <juri <at> linkov.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 74616 <at> debbugs.gnu.org,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#74616: 30.0.92; tmm always displays the *Completions* buffer
Date: Mon, 09 Dec 2024 20:28:06 +0100

Juri Linkov <juri <at> linkov.net> writes:

>> I attached a patch which adds a customization option
>> `completion-eager-display' and an `eager-display' completion table
>> metadata. The customization option can be set to nil (never), t (always)
>> or to auto, which means that the *Completions* buffer will only be shown
>> if the completion table requests eager display via the `eager-display'
>> metadata.
>>
>> I updated ffap.el, tmm.el and imenu.el to take advantage of the new
>> `eager-display' metadata. I added completion categories where missing
>> such that overriding the metadata becomes possible. If desired, the
>> metadata can be moved to `completion-category-defaults' instead.
>
> Thanks, I tested everything, and it works nicely.

Thanks for testing!

> One small detail that could be added later is to extend
> the customization type of `completion-category-overrides'
> :value-type with `eager-display'.  Since currently
> only programmatic use is supported.

Okay, I will add this to to custom type.

> Also tried to do:
>
>   (add-to-list 'completion-category-overrides
>                '(tmm (eager-display . nil)))
>
> but after typing TAB it pops up the completion buffer
> where all functionality is lost.  Is this because
> `tmm-add-prompt' is called only for non-nil `eager-display'?

I see. The keymap is not set up properly anymore if
`tmm-add-prompt' is disabled. I will add a fix.

Daniel

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Juri Linkov <juri <at> linkov.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 74616 <at> debbugs.gnu.org,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#74616: 30.0.92; tmm always displays the *Completions* buffer
Date: Mon, 09 Dec 2024 20:52:25 +0100

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

Juri Linkov <juri <at> linkov.net> writes:

>> I attached a patch which adds a customization option
>> `completion-eager-display' and an `eager-display' completion table
>> metadata. The customization option can be set to nil (never), t (always)
>> or to auto, which means that the *Completions* buffer will only be shown
>> if the completion table requests eager display via the `eager-display'
>> metadata.
>>
>> I updated ffap.el, tmm.el and imenu.el to take advantage of the new
>> `eager-display' metadata. I added completion categories where missing
>> such that overriding the metadata becomes possible. If desired, the
>> metadata can be moved to `completion-category-defaults' instead.
>
> Thanks, I tested everything, and it works nicely.
>
> One small detail that could be added later is to extend
> the customization type of `completion-category-overrides'
> :value-type with `eager-display'.  Since currently
> only programmatic use is supported.
>
> Also tried to do:
>
>   (add-to-list 'completion-category-overrides
>                '(tmm (eager-display . nil)))
>
> but after typing TAB it pops up the completion buffer
> where all functionality is lost.  Is this because
> `tmm-add-prompt' is called only for non-nil `eager-display'?

See the new patch which I've attached to this mail, with the two
improvements.

Daniel

[0001-New-customization-variable-completion-eager-display.patch (text/x-diff, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: 74616 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca, juri <at> linkov.net
Subject: Re: bug#74616: 30.0.92; tmm always displays the *Completions* buffer
Date: Mon, 09 Dec 2024 22:06:48 +0200

> From: Daniel Mendler <mail <at> daniel-mendler.de>
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>,  Eli Zaretskii
>  <eliz <at> gnu.org>,  74616 <at> debbugs.gnu.org
> Date: Mon, 09 Dec 2024 20:28:06 +0100
> 
> Juri Linkov <juri <at> linkov.net> writes:
> 
> > One small detail that could be added later is to extend
> > the customization type of `completion-category-overrides'
> > :value-type with `eager-display'.  Since currently
> > only programmatic use is supported.
> 
> Okay, I will add this to to custom type.

Please also add a :version tag.

The doc string of the defcustom could also be improved.  I think the
first line should say

  Whether completion commands should display *Completions* buffer eagerly.

Also, the part about requesting the eager display via the
`eager-display' metadata should probably be expanded, because it's too
terse to be useful.  I would also suggest to explain what "eagerly"
means in this ciontext.

Thanks.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: 74616 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca, juri <at> linkov.net
Subject: Re: bug#74616: 30.0.92; tmm always displays the *Completions* buffer
Date: Mon, 09 Dec 2024 22:08:08 +0200

> From: Daniel Mendler <mail <at> daniel-mendler.de>
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>,  Eli Zaretskii
>  <eliz <at> gnu.org>,  74616 <at> debbugs.gnu.org
> Date: Mon, 09 Dec 2024 20:52:25 +0100
> 
> See the new patch which I've attached to this mail, with the two
> improvements.

Does this deserve a NEWS entry?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: mail <at> daniel-mendler.de
Cc: 74616 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca, juri <at> linkov.net
Subject: Re: bug#74616: 30.0.92; tmm always displays the *Completions* buffer
Date: Mon, 09 Dec 2024 22:12:02 +0200

> Cc: 74616 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca, juri <at> linkov.net
> Date: Mon, 09 Dec 2024 22:06:48 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> Please also add a :version tag.
> 
> The doc string of the defcustom could also be improved.  I think the
> first line should say
> 
>   Whether completion commands should display *Completions* buffer eagerly.
> 
> Also, the part about requesting the eager display via the
> `eager-display' metadata should probably be expanded, because it's too
> terse to be useful.  I would also suggest to explain what "eagerly"
> means in this ciontext.

Oh, and please also mention the bug number in the commit log message.

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 74616 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca, juri <at> linkov.net
Subject: Re: bug#74616: 30.0.92; tmm always displays the *Completions* buffer
Date: Mon, 09 Dec 2024 21:32:49 +0100

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

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Daniel Mendler <mail <at> daniel-mendler.de>
>> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>,  Eli Zaretskii
>>  <eliz <at> gnu.org>,  74616 <at> debbugs.gnu.org
>> Date: Mon, 09 Dec 2024 20:52:25 +0100
>> 
>> See the new patch which I've attached to this mail, with the two
>> improvements.
>
> Does this deserve a NEWS entry?

I've added a :version tag to the defcustom and expanded the docstring.
Furthermore the commit message includes the bug numbers and there is a
NEWS entry. See the updated patch attached to this mail.

Daniel

[0001-New-customization-variable-completion-eager-display.patch (text/x-diff, attachment)]

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

From: Juri Linkov <juri <at> linkov.net>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 74616 <at> debbugs.gnu.org,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#74616: 30.0.92; tmm always displays the *Completions* buffer
Date: Tue, 10 Dec 2024 09:43:31 +0200

> See the new patch which I've attached to this mail, with the two
> improvements.

Thanks, I confirm that now everything works nicely.

BTW, after customizing 'completion-eager-display' to t, its behavior
looks like the option 'icomplete-show-matches-on-no-input', and reminds
the plans to implement the updating *Completions* as you type.
So `eager-display' could be the first step for implementing
`eager-update' as well.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: 74616 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca, juri <at> linkov.net
Subject: Re: bug#74616: 30.0.92; tmm always displays the *Completions* buffer
Date: Tue, 10 Dec 2024 14:32:11 +0200

> From: Daniel Mendler <mail <at> daniel-mendler.de>
> Cc: juri <at> linkov.net,  monnier <at> iro.umontreal.ca,  74616 <at> debbugs.gnu.org
> Date: Mon, 09 Dec 2024 21:32:49 +0100
> 
> > Does this deserve a NEWS entry?
> 
> I've added a :version tag to the defcustom and expanded the docstring.
> Furthermore the commit message includes the bug numbers and there is a
> NEWS entry. See the updated patch attached to this mail.

Thanks.  This LGTM (but let's leave some time for others to chime in),
with the following nit:

> ++++
> +*** New user option 'completion-eager-display'.
> +This option configures whether completion commands should display
> +the *Completions* buffer immediately.  When the variable is set to t all
> +completion commands show *Completions* immediately, respectively nil
> +disables the eager display for all commands. The default setting auto
                                              ^^
Two spaces there, please.

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 74616 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca, juri <at> linkov.net
Subject: Re: bug#74616: 30.0.92; tmm always displays the *Completions* buffer
Date: Wed, 11 Dec 2024 16:37:18 +0100

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

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Daniel Mendler <mail <at> daniel-mendler.de>
>> Cc: juri <at> linkov.net,  monnier <at> iro.umontreal.ca,  74616 <at> debbugs.gnu.org
>> Date: Mon, 09 Dec 2024 21:32:49 +0100
>> 
>> > Does this deserve a NEWS entry?
>> 
>> I've added a :version tag to the defcustom and expanded the docstring.
>> Furthermore the commit message includes the bug numbers and there is a
>> NEWS entry. See the updated patch attached to this mail.
>
> Thanks.  This LGTM (but let's leave some time for others to chime in),
> with the following nit:
>
>> ++++
>> +*** New user option 'completion-eager-display'.
>> +This option configures whether completion commands should display
>> +the *Completions* buffer immediately.  When the variable is set to t all
>> +completion commands show *Completions* immediately, respectively nil
>> +disables the eager display for all commands. The default setting auto
>                                               ^^
> Two spaces there, please.

Thanks. Updated patch attached.

[0001-New-customization-variable-completion-eager-display.patch (text/x-diff, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: 74616 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca, juri <at> linkov.net
Subject: Re: bug#74616: 30.0.92; tmm always displays the *Completions* buffer
Date: Sat, 14 Dec 2024 12:31:28 +0200

> From: Daniel Mendler <mail <at> daniel-mendler.de>
> Cc: juri <at> linkov.net,  monnier <at> iro.umontreal.ca,  74616 <at> debbugs.gnu.org
> Date: Wed, 11 Dec 2024 16:37:18 +0100
> 
> > Thanks.  This LGTM (but let's leave some time for others to chime in),
> > with the following nit:
> >
> >> ++++
> >> +*** New user option 'completion-eager-display'.
> >> +This option configures whether completion commands should display
> >> +the *Completions* buffer immediately.  When the variable is set to t all
> >> +completion commands show *Completions* immediately, respectively nil
> >> +disables the eager display for all commands. The default setting auto
> >                                               ^^
> > Two spaces there, please.
> 
> Thanks. Updated patch attached.

Thanks.  I was about to install this, but it turns out it breaks
minibuffer-tests:

  Test minibuffer-next-completion backtrace:
    string-match("\\(?:^\\|[^$]\\(?:\\$\\$\\)*\\)\\$\\([[:alnum:]_]*\\|{
    completion--embedded-envvar-table(nil nil metadata)
    complete-with-action(metadata completion--embedded-envvar-table nil
    #f(compiled-function (table) #<bytecode 0x1236ddf24c840ff1>)(complet
    #f(compiled-function (elt) #<bytecode 0x1c06dcd8a3b9e12b>)(completio
    mapc(#f(compiled-function (elt) #<bytecode 0x1c06dcd8a3b9e12b>) (com
    seq-do(#f(compiled-function (elt) #<bytecode 0x1c06dcd8a3b9e12b>) (c
    seq-some(#f(compiled-function (table) #<bytecode 0x1236ddf24c840ff1>
    read-file-name-internal(nil nil metadata)
    completion-metadata(nil read-file-name-internal nil)
    #f(compiled-function () #<bytecode -0x1755b58031bea2df>)()
    minibuffer-setup()
    read-from-minibuffer("Prompt: " nil (keymap (menu-bar keymap (minibu
    completing-read-default("Prompt: " read-file-name-internal nil nil n
    completing-read("Prompt: " read-file-name-internal)
    (let ((executing-kbd-macro t)) (completing-read "Prompt: " #'read-fi
    (progn (add-hook 'minibuffer-setup-hook setup-hook) (let ((executing
    (unwind-protect (progn (add-hook 'minibuffer-setup-hook setup-hook)
    (let ((fun #'(lambda nil (let ((redisplay-skip-initial-frame nil) (e
    (catch 'result (let ((fun #'(lambda nil (let (... ...) (throw ... ..
    (let ((default-directory (let* ((testfile (and t "d:/gnu/git/emacs/t
    #f(lambda () [t] (let ((default-directory (let* ... ...))) (catch 'r
    #f(compiled-function () #<bytecode -0x3a7832479b8d919>)()
    handler-bind-1(#f(compiled-function () #<bytecode -0x3a7832479b8d919
    ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
    ert-run-test(#s(ert-test :name minibuffer-next-completion :documenta
    ert-run-or-rerun-test(#s(ert--stats :selector ... :tests ... :test-m
    ert-run-tests((not (or (tag :unstable) (tag :nativecomp))) #f(compil
    ert-run-tests-batch((not (or (tag :unstable) (tag :nativecomp))))
    ert-run-tests-batch-and-exit((not (or (tag :unstable) (tag :nativeco
    eval((ert-run-tests-batch-and-exit '(not (or (tag :unstable) (tag :n
    command-line-1(("-L" ";." "-l" "ert" "--eval" "(setq treesit-extra-l
    command-line()
    normal-top-level()
  Test minibuffer-next-completion condition:
      (wrong-type-argument stringp nil)
     FAILED  31/31  minibuffer-next-completion (0.001079 sec) at lisp/minibuffer-tests.el:646

  Ran 31 tests, 30 results as expected, 1 unexpected (2024-12-14 12:28:17+0200, 0.563908 sec)

  1 unexpected results:
     FAILED  minibuffer-next-completion

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 74616 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca, juri <at> linkov.net
Subject: Re: bug#74616: 30.0.92; tmm always displays the *Completions* buffer
Date: Sat, 14 Dec 2024 12:44:48 +0100

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

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Daniel Mendler <mail <at> daniel-mendler.de>
>> Cc: juri <at> linkov.net,  monnier <at> iro.umontreal.ca,  74616 <at> debbugs.gnu.org
>> Date: Wed, 11 Dec 2024 16:37:18 +0100
>> 
>> > Thanks.  This LGTM (but let's leave some time for others to chime in),
>> > with the following nit:
>> >
>> >> ++++
>> >> +*** New user option 'completion-eager-display'.
>> >> +This option configures whether completion commands should display
>> >> +the *Completions* buffer immediately.  When the variable is set to t all
>> >> +completion commands show *Completions* immediately, respectively nil
>> >> +disables the eager display for all commands. The default setting auto
>> >                                               ^^
>> > Two spaces there, please.
>> 
>> Thanks. Updated patch attached.
>
> Thanks.  I was about to install this, but it turns out it breaks
> minibuffer-tests:

Thanks for finding this. The problem was that `initial-input' was passed
directly to `completion-metadata'. I replaced `initial-input' with `(or
initial-input "")'. See the updated patch attached to this mail.

Daniel

[0001-New-customization-variable-completion-eager-display.patch (text/x-diff, attachment)]

Message #88 received at 74616-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: monnier <at> iro.umontreal.ca, 74616-done <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#74616: 30.0.92; tmm always displays the *Completions* buffer
Date: Sat, 14 Dec 2024 14:40:12 +0200

> From: Daniel Mendler <mail <at> daniel-mendler.de>
> Cc: juri <at> linkov.net,  monnier <at> iro.umontreal.ca,  74616 <at> debbugs.gnu.org
> Date: Sat, 14 Dec 2024 12:44:48 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> From: Daniel Mendler <mail <at> daniel-mendler.de>
> >> Cc: juri <at> linkov.net,  monnier <at> iro.umontreal.ca,  74616 <at> debbugs.gnu.org
> >> Date: Wed, 11 Dec 2024 16:37:18 +0100
> >> 
> >> > Thanks.  This LGTM (but let's leave some time for others to chime in),
> >> > with the following nit:
> >> >
> >> >> ++++
> >> >> +*** New user option 'completion-eager-display'.
> >> >> +This option configures whether completion commands should display
> >> >> +the *Completions* buffer immediately.  When the variable is set to t all
> >> >> +completion commands show *Completions* immediately, respectively nil
> >> >> +disables the eager display for all commands. The default setting auto
> >> >                                               ^^
> >> > Two spaces there, please.
> >> 
> >> Thanks. Updated patch attached.
> >
> > Thanks.  I was about to install this, but it turns out it breaks
> > minibuffer-tests:
> 
> Thanks for finding this. The problem was that `initial-input' was passed
> directly to `completion-metadata'. I replaced `initial-input' with `(or
> initial-input "")'. See the updated patch attached to this mail.

Thanks, now installed on the master branch, and closing the bug.

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

From: Juri Linkov <juri <at> linkov.net>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 74616 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#74616: 30.0.92; tmm always displays the *Completions* buffer
Date: Sun, 15 Dec 2024 09:44:00 +0200

> Thanks for finding this. The problem was that `initial-input' was passed
> directly to `completion-metadata'. I replaced `initial-input' with `(or
> initial-input "")'. See the updated patch attached to this mail.

It seems this change caused another regression: 'ffap' on a file name
fails with the error:

Debugger entered--Lisp error: (wrong-type-argument stringp ("/tmp/file" . 6))
  completion--embedded-envvar-table(("/tmp/file" . 6) file-exists-p metadata)
  complete-with-action(metadata completion--embedded-envvar-table ("/tmp/file" . 6) file-exists-p)
  read-file-name-internal(("/tmp/file" . 6) file-exists-p metadata)
  completion-metadata(("/tmp/file" . 6) read-file-name-internal file-exists-p)
  minibuffer-setup()
  completing-read-default("Find file or URL: " read-file-name-internal file-exists-p nil ("/tmp/file" . 5) file-name-history "/tmp/file" nil)
  read-file-name-default("Find file or URL: " "/tmp/" nil nil "file" nil)
  read-file-name("Find file or URL: " "/tmp/" nil nil "file")
  ffap-read-file-or-url("Find file or URL: " "./file")
  ffap-prompter()
  ffap()
  funcall-interactively(ffap)
  command-execute(ffap record)
  execute-extended-command(nil "ffap" "ffap")
  funcall-interactively(execute-extended-command nil "ffap" "ffap")
  command-execute(execute-extended-command)

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Juri Linkov <juri <at> linkov.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 74616 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#74616: 30.0.92; tmm always displays the *Completions* buffer
Date: Sun, 15 Dec 2024 11:02:29 +0100

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

Juri Linkov <juri <at> linkov.net> writes:

>> Thanks for finding this. The problem was that `initial-input' was passed
>> directly to `completion-metadata'. I replaced `initial-input' with `(or
>> initial-input "")'. See the updated patch attached to this mail.
>
> It seems this change caused another regression: 'ffap' on a file name
> fails with the error:

Oh, I see. The INITIAL-INPUT argument can be a cons pair too.  See the
patch attached to this mail which fixes the problem.

Daniel

[0001-completion-eager-display-Handle-INITIAL-INPUT-cons.patch (text/x-diff, attachment)]

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Juri Linkov <juri <at> linkov.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 74616 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#74616: 30.0.92; tmm always displays the *Completions* buffer
Date: Sun, 15 Dec 2024 16:29:19 +0100

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

Daniel Mendler <mail <at> daniel-mendler.de> writes:

> Juri Linkov <juri <at> linkov.net> writes:
>
>>> Thanks for finding this. The problem was that `initial-input' was passed
>>> directly to `completion-metadata'. I replaced `initial-input' with `(or
>>> initial-input "")'. See the updated patch attached to this mail.
>>
>> It seems this change caused another regression: 'ffap' on a file name
>> fails with the error:
>
> Oh, I see. The INITIAL-INPUT argument can be a cons pair too.  See the
> patch attached to this mail which fixes the problem.

I've attached an ever better patch to this mail, where the minibuffer
content is simply used directly instead of handling the different
INITIAL-INPUT cases. This is simpler and more future proof.

Daniel

[0001-completion-eager-display-Use-buffer-content-instead-.patch (text/x-diff, attachment)]

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 74616 <at> debbugs.gnu.org,
 Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#74616: 30.0.92; tmm always displays the *Completions* buffer
Date: Sun, 15 Dec 2024 18:04:40 -0500

> I've attached an ever better patch to this mail, where the minibuffer
> content is simply used directly instead of handling the different
> INITIAL-INPUT cases. This is simpler and more future proof.

Thanks, pushed to `master`.


        Stefan

Previous Next

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