[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: |
Wed, 25 Nov 2020 21:09:47 +0000 |
Hello, Martin.
On Wed, Nov 25, 2020 at 10:25:46 +0100, martin rudalics wrote:
> > Fine. I will push this to Emacs 27.2.
> Done. Alan, the following two concerns are still awaiting a fix:
OK.
> Madhu's:
> These patches introduce a regression on "graphical" emacs -
> 1. emacs -Q
> 2. M-: (setq pop-up-frames 'graphic-only)
> 3. M-! g <TAB>
> This should pop up a *Completions* buffer in a new frame.
> On choosing the completion (via a button1 or by navigating to the
> desired point and typing RET) - the frame should be automatically
> hidden[1]
> This doesn't happen anymore and the completion buffer and frame remain
> there taking up focus.
I've started looking at this. It could take some time to resolve.
> [1] default value for frame-auto-hide-function is #'iconify-frame, but
> if your window manager cannot iconify it, set
> (setq frame-auto-hide-function #'delete-frame)
> Andrii's:
> It is not producing bugs for me, but changes behavior.
This is inevitable, even if regrettable.
> E.g. in emacs -Q:
> 1. Evaluate
> (select-frame-set-input-focus
> (make-frame '((minibuffer . only)
> (left . 1.0))))
> 2. M-x
> 3. C-x 5 o
> Before minibuffer-follows-selected-frame, the prompt stays in the
> minibuffer-only frame.
> On recent master, the prompt is moved to other frame leaving
> minibuffer-only frame empty. 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.
The behaviour in Emacs 27 is chaotic. Sometimes a minibuffer moves with
a frame switch, sometimes it doesn't. The change in master is intended
to make the behaviour logical and systematic.
As to why minibuffer-follows-selected-frame is t by default, there is no
particular reason. It transpired that Eli and I had different mental
models of the connection between minibuffers and frames. The setting t
represents Eli's model rather than mine (?ours). Setting it to nil by
default would also cause annoyance, in different ways.
Also, how often do people actually select minibuffer-only frames?
Unless I'm missing something, it seems a rather strange thing to want to
do.
> martin
--
Alan Mackenzie (Nuremberg, Germany).
- Re: Stop frames stealing eachothers' minibuffers!, (continued)
- Re: Stop frames stealing eachothers' minibuffers!, Gregory Heytings, 2020/11/23
- Re: Stop frames stealing eachothers' minibuffers!, Andrii Kolomoiets, 2020/11/23
- Re: Stop frames stealing eachothers' minibuffers!, martin rudalics, 2020/11/24
- Re: Stop frames stealing eachothers' minibuffers!, martin rudalics, 2020/11/24
- Re: Stop frames stealing eachothers' minibuffers!, martin rudalics, 2020/11/24
- Re: Stop frames stealing eachothers' minibuffers!, Gregory Heytings, 2020/11/24
- Re: Stop frames stealing eachothers' minibuffers!, martin rudalics, 2020/11/24
- Re: Stop frames stealing eachothers' minibuffers!, martin rudalics, 2020/11/25
- Re: Stop frames stealing eachothers' minibuffers!,
Alan Mackenzie <=
- Re: Stop frames stealing eachothers' minibuffers!, Gregory Heytings, 2020/11/25
- Re: Stop frames stealing eachothers' minibuffers!, Alan Mackenzie, 2020/11/25
- Re: Stop frames stealing eachothers' minibuffers!, Gregory Heytings, 2020/11/25
- Re: Stop frames stealing eachothers' minibuffers!, Alan Mackenzie, 2020/11/27
- Re: Stop frames stealing eachothers' minibuffers!, Gregory Heytings, 2020/11/27
- Re: Stop frames stealing eachothers' minibuffers!, Gregory Heytings, 2020/11/27
- Re: Stop frames stealing eachothers' minibuffers!, Alan Mackenzie, 2020/11/27
- Re: Stop frames stealing eachothers' minibuffers!, Gregory Heytings, 2020/11/27
- Re: Stop frames stealing eachothers' minibuffers!, Alan Mackenzie, 2020/11/27
- Re: Stop frames stealing eachothers' minibuffers!, Gregory Heytings, 2020/11/27