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: Gregory Heytings
Subject: bug#45474: Icomplete exhibiting in recursive minibuffer when it shouldn’t
Date: Fri, 23 Apr 2021 13:45:47 +0000


It seems to me that my proposal is better, and here's why. The right thing to do in this case is not to install a local fix in completing-read-default, because completing-read-default is not where the root cause of the current problem lies.

Hmm... that's odd: the problem has to do with values of `minibuffer-completion-*` appearing where they shouldn't, and those values are set by `completing-read-default`, so I think it's clearly the culprit.


By 'completing-read-default' _and_ by other completion backends that set minibuffer-completion-* elements and call read-from-minibuffer. Or am I misunderstanding something?

If not, it means that your patch will fix the problem for completing-read-default, but not for other completion backends, who will have to resort on a similar trick to get the same effect. IMO it would be better to avoid that, and to give "read-from-minibuffer" the new semantics that it takes some arguments from the environment and that these arguments are not anymore visible by all other (recursive) uses of read-from-minibuffer.

The right thing to do is to change the semantics of read-from-minibuffer (while preserving backward compatibility for a limited amount of time), in such a way it receives some of its arguments through its environment.

The core problem is the fact that dynamic scoping leaks: the parameters passed to `read-from-minibuffer` via dynamic scoping and up being passed to all other uses of `read-from-minibuffer` which happen to take place within the same dynamic extent.


Not with the patch I'm proposing. What it does is the following (in abbreviated form):

(let ((minibuffer-local-* minibuffer-completion-*))
   (let ((minibuffer-completion-* nil))
      (internal-read-from-minibuffer ...)))

Line 1 saves the parameters in temporary variables, and line 2 resets the values of the parameters to nil, which means that they will not be visible anymore to all other uses of read-from-minibuffer within the same dynamic extent. Isn't that a nice trick?

So you get all you want at once:

- receiving the arguments from the environment (thereby avoiding to add new explicit parameters)

- buffer-local values of the arguments on demand (thereby getting better semantics for callers that want it, in particular completing-read-default)

- be backward compatible the current semantics of read-from-minibufer (thereby avoiding to break compatibility for callers that did not adapt to the the new semantics)





reply via email to

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