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

Previous Next

Full log

Message #20 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 14:30:32 +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 10:40:05 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> > 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.

I don't understand: ffap-menu calls completing-read, so what
abstraction does it bypass, and how?

> It is not the responsibility of
> alternative completion UIs to work around this.

Work around what?

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

The question is: who should pay attention and understand that "the
other" completion is being called?

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

You assume that the completion table is never passed to inner levels?
Is that assumption solid?

Previous Next

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