GNU bug report logs - #74617
30.0.92; ffap-menu always displays the *Completions* buffer

Previous Next

Full log

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

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

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

>> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>
>> Date: Sat, 30 Nov 2024 08:02:20 +0100
>> From:  Daniel Mendler via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>> 
>> `ffap-menu' 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.
>
> That's not what I see here.  Recipe:
>
>   emacs -Q
>   M-x icomplete-mode RET
>   C-x C-f nt/INSTALL.W64 RET
>   M-x ffap-menu RET
>
> I see only the *Completions* buffer, no other display of the
> candidates.  What did I miss?

Oh, right. I missed that. I think the problem here is that Icomplete
uses a delay (`icomplete-compute-delay'). Other completion UIs don't
have such a delay and show the candidates immediately. This makes the
problem a little more difficult, in particular with respect to auto
detection.

Another alternative to auto detection could be that the completion table
communicates to `completing-read' via metadata that immediate candidate
display is desired. The completion UI could then act accordingly.
Default completion would call `minibuffer-completion-help' and Icomplete
could update immediately, ignoring `icomplete-compute-delay'.

Daniel

Previous Next

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