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: martin rudalics
Subject: Re: Stop frames stealing eachothers' minibuffers!
Date: Wed, 25 Nov 2020 10:25:46 +0100

> Fine.  I will push this to Emacs 27.2.

Done.  Alan, the following two concerns are still awaiting a fix:


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.


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

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.


martin



reply via email to

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