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



reply via email to

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