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

Previous Next

Full log

Message #17 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 10:40:05 +0100

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

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

I see it differently. The problem is in the tmm and ffap commands which
lead to a mixture of completion UIs. Even if another completion UI is in
effect, the default completion UI is called by tmm and ffap, bypassing
the `completing-read' abstraction. It is not the responsibility of
alternative completion UIs to work around this. Mixing multiple
completion UIs is not ideal since it will lead to an incoherent UI and
also to conflicts in how the user interacts with the minibuffer.

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

By using the completion metadata as part of the completion table, the
effect on nested scenarios is explicitly avoided. Problems with nesting
only occur if a variable is let-bound around `completing-read'.

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

I care. But I do agree with you that the issues are minor and far from a
catastrophe.

The pattern where completion commands want to display candidates
immediately is not uncommon. There are ffap, tmm and multiple
third-party packages which have such a requirement. So I suggest to not
necessarily treat "immediate candidate display" as a bug report, but
rather as a feature request for `completing-read'.

Previous Next

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