emacs-devel
[Top][All Lists]
Advanced

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

Re: Setting `minibuffer-completion-table` buffer-locally


From: Gregory Heytings
Subject: Re: Setting `minibuffer-completion-table` buffer-locally
Date: Sat, 24 Apr 2021 13:38:13 +0000



There's a "competing" patch from Gregory which does something similar but in a slightly different way (less clean but potentially a bit more backward compatible), and I think in order to decide which is the best approach we need to have a more concrete information about the risk of breakage and what we might need to do to minimize it.


In the interest of fairness in the discussion and comparison, and given the length of the discussion in bug#45474, here is the "competing" patch.

The five major differences between the two approaches are (m-c-* stands for the minibuffer-completion-* variables, r-f-m for read-from-minibuffer, and m-w-s-h for minibuffer-with-setup-hook):

(1) SM: m-c-* variables are passed explicitly as arguments to r-f-m with a m-w-s-h, they are stricly buffer-local

GH: m-c-* variables are passed implicitly as arguments to r-f-m, they automatically become buffer-local upon entering the minibuffer

(2) SM: it is and it will remain necessary to use a m-w-s-h with setq-locals to have buffer-local m-c-* variables in r-f-m

GH: for Emacs 28 it is necessary to let-bind minibuffer-local-completion to t around the call to r-f-m (to preserve backward compatibility), for Emacs 29 and above minibuffer-local-completion t will be assumed (or, with the strong version: the only possible behavior)

(3) SM: when m-c-* variables are strictly buffer-local (i.e., when they are passed in a m-w-s-h to r-f-m), they cannot interfere with code outside of the minibuffer

GH: because m-c-* variables become buffer-local only upon entering the minibuffer, they can possibly interfere with code that is executed around the call to r-f-m, between the moment they have been let-bound and the moment they become buffer-local

(4) SM: the semantics of r-f-m is not changed

GH: the semantics of r-f-m is changed, in Emacs 28 the m-c-* variables become buffer-local when minibuffer-local-completion is t, in Emacs 29 they become buffer-local unless minibuffer-local-completion is nil (or, with the strong version: they become buffer-local)

(5) SM: the patch fixes the behavior of completing-read-default

GH: the patch fixes the behavior of completing-read-default and makes, in the medium term, that new behavior the default one for all uses of r-f-m

Attachment: competing.patch
Description: Text Data


reply via email to

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