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: Gregory Heytings
Subject: Re: Stop frames stealing eachothers' minibuffers!
Date: Fri, 27 Nov 2020 07:33:04 +0000
User-agent: Alpine 2.22 (NEB 394 2020-01-19)


[Apparently this email I sent a few hours ago did not reach the mailing list. I apologize if you receive it twice.]

I wouldn't write it is "chaotic". The behavior you consider "chaotic" is well-defined, and has been there since Emacs 21 at least: the minibuffer moves from frame F1 to frame F2 if and only if the minibuffer is active on frame F1 and a recursive minibuffer is entered on frame F2. There are other possible behaviors of course, but IMO the current one is a reasonable one.

The basic behavioral change I see is with 'enable-recursive-minibuffers' non-nil and two frames: When I type C-h f setq in the first frame and C-h f cons in the second frame, hit RET, reselect the minibuffer window and hit RET again, with Emacs 27 a help window pops up in the first frame while Emacs 28 reuses the help window of the second frame. In both cases the second RET goes to the second frame and both behaviors seem reasonable to me.

If, with Emacs 28, I set 'minibuffer-follows-selected-frame' to non-nil, the behavior does not entirely match that of Emacs 27 because the second RET must be typed in the first frame. So if some application relies on the exact replication of the behavior of Emacs 27, we have a regression.


Note that this patch and discussion started with the following observation (on Oct 13):

(i) Have two frames open displaying buffers.
(ii) On frame F1 do C-x b.  This leaves a minibuffer open there.
(iii) Move to F2.
(iv) Do C-x 8 RET <enter some character>.
F1's minibuffer is now on F2.  This is bad.

It is indeed not possible to replicate the behavior of Emacs 27 and earlier. What we have is, for example:

  | Emacs 21-27 | Emacs 28 with (setq m-f-s-f t) | Emacs 28 with (setq m-f-s-f 
nil)
A | MB1 on F1   | MB1 on F2                      | MB1 on F1
B | MB1+2 on F2 | MB1+2 on F2                    | MB1 on F1, MB2 on F2 [1]

A: type C-x C-f on frame F1, switch to frame F2
B: type C-x C-f on frame F1, switch to frame F2, type M-:

[1] There is also a severe regression in this case. Type C-x C-f on frame F1, switch to frame F2, type M-:. "Find file" is still visible in the miniwindow on frame F1; switch to frame F1.

Experiment 1: Type the name of a file and RET. You'll get the error message "End of file during parsing", and MB2 on frame F2 will be left. MB1 is now unuseable, and impossible to leave, it will stay on F1 whatever you do.

Experiment 2: Type C-g. MB2 on frame F2 will be left, and "Find file" will stay in MB1 on frame F1. However you cannot use it anymore, the keymap of MB1 is now minibuffer-inactive-mode-map. And like in experiment 1, you cannot leave it.



reply via email to

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