bug#48925: [PATCH] Set `minibuffer-completion-*` variables buffer-locally in a few more places

[miha--- via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

[-- Attachment #1: Type: text/plain, Size: 1710 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Lars Ingebrigtsen <larsi@gnus.org>
>> Cc: <miha@kamnitnik.top>,  monnier@iro.umontreal.ca,  48925@debbugs.gnu.org
>> Date: Thu, 11 Nov 2021 13:11:10 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > Moving read-string to subr.el means the function will be unavailable
>> > during loadup until subr.elc is loaded.
>> 
>> That's a worry, so I tried Miha's patch now and did both a "make" and a
>> "make bootstrap", and both completed without any problems.
>
> I didn't say it will be a problem now.  But it's a time bomb waiting
> to go off.  So I'd like to see if we could still do this in C.

In that case, my personal opinion is that it's okay to leave it as is
and close this bug.

The specbinding in `read-string' isn't a very big problem. The only
problematic case I can think of is quite specific: the user runs a
function that let-binds `minibuffer-completion-table' around a call to
`read-from-minibuffer' (this is the old convention, the new convection
is to set the completion table buffer locally), and then recursively
uses `read-string' during this minibuffer session on a separate frame
with `minibuffer-follows-selected-frame' customized to nil. Completion
commands will now not work in the outer minibuffer.

IMO, it's not really worth trying too hard to figure out a way to fix
this very specific issue in C. One simple solution would be to introduce
a new optional argument to `read-from-minibuffer', a function that would
be run in the minibuffer as an alternative to
minibuffer-with-setup-hook. I believe Stefan M. proposed something like
this, but this should probably be discussed more thoroughly.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]