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: Alan Mackenzie
Subject: Re: Stop frames stealing eachothers' minibuffers!
Date: Sat, 28 Nov 2020 10:45:34 +0000

Hello, Gregory and Martin.

On Fri, Nov 27, 2020 at 07:33:04 +0000, Gregory Heytings wrote:

[ .... ]

>   | 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.

The abstract cause of this situation would appear to be using F1's
minibuffer while a more deeply nested minibuffer is still active.  It is
a violation of the "recursive" nature of these buffers.

I think a solution would be to put F1's minibuffer into
minibuffer-inactive-mode until the recursive MB in F2 has terminated.

What do you think of this?

-- 
Alan Mackenzie (Nuremberg, Germany).



reply via email to

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