bug#74617: 30.0.92; ffap-menu always displays the *Completions* buffer

[Eli Zaretskii <eliz@gnu.org>]

> From: Daniel Mendler <mail@daniel-mendler.de>
> Cc: 74617@debbugs.gnu.org,  monnier@iro.umontreal.ca
> Date: Sat, 30 Nov 2024 10:40:05 +0100
> 
> Eli Zaretskii <eliz@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?