emacs-devel
[Top][All Lists]
Advanced

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

Re: Stop frames stealing eachothers' minibuffers!


From: Andrii Kolomoiets
Subject: Re: Stop frames stealing eachothers' minibuffers!
Date: Wed, 11 Nov 2020 00:54:35 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (darwin)

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I don't sure what the "in the wild" means, but I know at least two
>> packages that shows minibuffer-only child frame on reading user input:
>>
>> https://raw.githubusercontent.com/honmaple/emacs-maple-minibuffer/master/maple-minibuffer.el
>>
>> https://raw.githubusercontent.com/muffinmad/emacs-mini-frame/master/mini-frame.el
>
> Indeed, great examples, thanks.
>
>> I can't report this as a bug.  Just wondering why
>> minibuffer-follows-selected-frame is set to t by default, potentially
>> changing someone's expected behavior.
>
> I think the reason is that it more closely mimics what happens with the
> echo area and it arguably (philosophically) better matches the default
> setting of `enable-recursive-minibuffers`.

Maybe I'm missing something, but the message "Command attempted to use
minibuffer while in minibuffer" is displayed in other frame, just like
in Emacs 27.

> But if it results in regressions with packages to maple-minibuffer or
> mini-frame, we should of course try and address that (either by refining
> the behavior or by changing the default).

Well, mini-frame-mode already has a (not so pretty) workaround for the
new behavior: set the global option on mode activation.

Probably the better solution will be to not take the minibuffer away
from minibuffer-only frames.  After all, it's all they got :)



reply via email to

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