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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Mendler <mail <at> daniel-mendler.de>
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 11:28:13 +0200

> From: Daniel Mendler <mail <at> daniel-mendler.de>
> Cc: 74617 <at> debbugs.gnu.org,  monnier <at> iro.umontreal.ca
> Date: Sat, 30 Nov 2024 09:34:11 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >   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.

Alternatively, we could consider the cases where more than one
completion list is shown a bug in the mode which shows the completions
even though the application already did.  IOW, instead of considering
this a problem of the command the user invokes, consider this a bug in
the non-default completion UI currently in effect.  It is basically a
flaw in the design of those completion UIs.

> 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'.

This sounds too indirect to me, it could cause unintended adverse
consequences, especially in nested scenarios.

There's a simpler alternative: we could say we don't care, as long as
only a few alternative UIs have this issue.  It isn't a catastrophe.

Previous Next

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