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: Eli Zaretskii
Subject: Re: Stop frames stealing eachothers' minibuffers!
Date: Wed, 14 Oct 2020 20:43:09 +0300

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: acm@muc.de,  emacs-devel@gnu.org
> Date: Wed, 14 Oct 2020 13:22:28 -0400
> 
> >> >> Seeing as how a minibuffer often has a strong association with its frame
> >> >> (e.g., C-x C-f opens a buffer in the same frame it was invoked from),
> >> >> this shifting of minibuffers from one frame to another is confusing.
> >> > Is it?  It makes sure the minibuffer is on the selected frame, which
> >> > is natural in many/most use cases.
> >> But it only makes sure after you used another minibuffer
> > Maybe that's the bug we should fix, then?
> 
> You mean, we'd make the active minibuffer follow along with changes to
> the selected frame?  Yes, that would be more consistent.
> I think that's what we do with the echo area already, so there's
> precedent for it.

Yes.

> I can't tell if it would be an improvement or a regression (I think it
> wouldn't affect my use cases either way).
> 
> 
>         Stefan
> 
> 
> PS: Just trying out now the echo-area case to check I remembered it
> right, I see we have a bug there (that dates back to Emacs-25 at least):
> 
>     % emacs -Q src/emacs.c
>     C-x 5 b RET
>     M-: (message "hello") RET
>     ... use your window manager to select the other frame ...
> 
> we now see "hello" in both miniwindows, whereas I expected it to be seen
> only in the selected frame (i.e. to be erased from the previously
> selected frame).
> 
>     C-g
> 
> we now see "Quit" in one of the miniwindows and "hello" in the other.

We are slowly eradicating problems like this one.  Alan's proposal
suggests that we move in the opposite direction, which I think would
be a mistake.



reply via email to

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