bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#45474: Icomplete exhibiting in recursive minibuffer when it shouldn’


From: Stefan Monnier
Subject: bug#45474: Icomplete exhibiting in recursive minibuffer when it shouldn’t
Date: Mon, 19 Apr 2021 11:57:59 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

> There are 76 calls to read-from-minibuffer on ELPA.  AFAICS, the only call
> that uses minibuffer-completion-table is the one iside ivy-read.
[...]
> There are 903 calls to read-from-minibuffer on MELPA.  AFAICS, only
> a handful of them (yatex, gams-mode, python-django, magit) use
> minibuffer-completion-table.  The case of Magit is interesting: it solves
> the current problem by defining two functions,
> magit-completing-read-multiple that let-binds minibuffer-completion-table to
> the appropriate value, and magit-read-string that let-binds
> minibuffer-completion-table to nil.

[ Thanks for the footwork.  ]

So the whitelist approach we're considering would break and few cases
like `ivy-read`, and `magit-completing-read-multiple` and would fix the
corner case misbehavior in hundred of other calls.

The blacklist approach would instead not break anything but would
require adding extra code to a few hundred places to fix those corner
case misbehaviors.

I'm starting to feel that neither option is very attractive.
I think we should:
- Do something along the lines of the whitelist approach, as the
  "long term" solution.
- Add to it some "short term" heuristic (e.g. using something like the
  "equal keymap" or the minibuffer depth) that keeps it working for
  ivy-read and friends, maybe emitting a warning along the way (and with
  a clean way to silence this warning when it's a false positive) so we
  can remove the heuristic in Emacs-30.

WDYT?

>> No, I meant that instead of using let-binding to set the var, we'd use
>> `setq-local`. This requires the code to run from within the minibuffer,
>> contrary to the current situation where the let-binding takes place
>> outside of the minibuffer.
> Yes, I understood this, but the effect of let-binding the var and make it
> buffer-local after the minibuffer has been created but before the
> minibuffer-setup-hook is executed is the same.  Or am I missing something?

[ Note: I consider this part of the discussion as not directly relevant to
  bug#45474.  ]

Oh, so `read-from-minibuffer` receives it as an "implicit argument" vet
dynamically scoped let-binding and then sets it buffer locally?

That sounds like a potentially good halfway point, so code which
(incorrectly) uses `minibuffer-completion-table` from non-mini buffers
will still usually get the right table (e.g. when there's only one
minibuffer active).

> If not, this would solve the problem without breaking anything (as the
> global value of minibuffer-completion-table would not change).

Exactly.


        Stefan






reply via email to

[Prev in Thread] Current Thread [Next in Thread]