[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: |
Sun, 10 Jan 2021 00:53:36 +0000 |
Hello, Martin.
On Thu, Jan 07, 2021 at 19:26:02 +0100, martin rudalics wrote:
> > Actualy, I don't think it's as ugly as all that.
> > select-frame-set-input-focus is an extremely coherent function; it does
> > one thing and does it well, i.e. switch frames. Maybe it's a pity that
> > it's a Lisp function rather than a C function, but it is as it is.
> It does call 'raise-frame' something people with 'focus-follows-mouse' t
> (not 'auto-raise') might not want here. And it may have to move the
> mouse cursor according to the 'mouse-autoselect-window' and
> 'focus-follows-mouse' policies. Most window managers don't handle the
> latter well (IIRC only the otherwise abominable mutter and KDE could do
> it approximately). And the former wants the selected window to be set
> up well before calling 'select-frame-set-input-focus'.
It is nevertheless the standard function to call to move focus to a
different frame. If there are problems with focus-follows-mouse, they
should surely be fixed in frame.el as a separate problem.
> > I've been trying to think through the bit about redirect-frame-focus.
> > It's difficult. Are you aware of any particular scenarios where it might
> > go wrong with select-frame-set-input-focus? Or is it more a general
> > concern, possibly from past experience? For example if the source frame
> > has focus redirected to a MB-only frame, and s-f-s-i-focus is called,
> > should that redirected focus be undone? I'm a little confused about the
> > difference between a MB-only frame being the selected frame, and it being
> > the focus frame of a different "normal" frame.
> I already had to revert one change because I got that wrong. It's again
> mostly about using 'focus-follows-mouse' t with a standalone minibuffer
> frame and I've never been able to understand how people manage that when
> the normal frame practically completely covers the minibuffer frame.
> But sooner or later this point will get moot because with Wayland people
> will be no more able to put a standalone minibuffer frame wherever they
> want to.
OK. My gut feeling is just to ignore this potential problem at the
moment.
> >> We're right in hell's kitchen here.
> > I've actually implemented the above, on a trial basis. It was actually
> > surprisingly easy. The C-g bit was just 9 extra lines (plus comments) in
> > internal_catch (eval.c), and another small function in minibuf.c.
> > You say "hell's kitchen". Again, is this on general principles,
> Just gut feeling.
OK. I can understand that. ;-)
> > or can
> > you see some specific problems which might crop up? My feeling is that
> > this way of dealing with "not the innermost minibuffer" is simple, and
> > possibly as good as we're going to get.
My intention at the moment is to commit my current state of work. I'm
attaching the patch.
Here's a commit message to go with it:
Fix incompleteness in the implementation of minibuffer-follows-selected-frame
In particular, add a new value to the variable, and fix several bugs apparent
with the implementation up till now.
* doc/emacs/mini.texi (Basic Minibuffer): Add a description of the new
non-nil, non-t value of minibuffer-follows-selected-frame.
* doc/emacs/trouble.texi (Quitting): Add a description of how C-g handles
recursive minibuffers when typed in one which isn't the most nested.
* doc/lispref/minibuf.texi (Intro to Minibuffers): Add an @dfn for "active
minibuffer".
(Minibuffer Commands): Document that exit-minibuffer throws an error when not
invoked from the innermost Minibuffer.
(Recursive Mini): Amend the description of the visibility of outer level
minibuffers.
(Minibuffer Misc): In the description of the minibuffer hooks, replace "the
minibuffer" with "a minibuffer".
* etc/NEWS (Entry announcing minibuffer-follows-selected-frame): Add a
description of the new non-nil, non-t value.
* lisp/cus-start.el (top level): make the customize entry for
minibuffer-follows-selected-frame a choice between three entries.
* lisp/minibuffer.el (exit-minibuffer): throw an error when we're not in the
most nested minibuffer.
* lisp/window.el (window-deletable-p): return the symbol `frame' when (amongst
other things) minibuffer-follows-selected-frame is t.
* src/eval.c (internal_catch): Add a mechanism to (throw 'exit t) repeatedly
when the throw currently being processed doesn't terminate the current
minibuffer.
* src/lisp.h (this_minibuffer_depth): New extern declaration
(minibuf_level): extern declaration moved here from window.h.
* src/minibuf.c (minibuffer_follows_frame, minibuf_stays_put)
(minibuf_moves_frame_when_opened): New and amended functions to query the
value of minibuffer-follows-selected-frame.
(choose_minibuf_frame): check (minibuf > 1) in place of (minibufer > 0) at a
particular place. At another place, check that an alleged frame is so and is
live. Before selecting a non-miniwindow on a different frame, ensure it
really is a different frame.
(move_minibuffer_onto_frame): Stack up all recursive minibuffers on the target
frame. Check the minibuf_window isn't in the old frame before setting that
frame's miniwindow to an inactive minibuffer.
(Finnermost_minibuffer_p): New primitive.
(this_minibuffer_depth): New function.
(read_minibuf): Record the calling frame in a variable, and switch back to it
after the recursive edit has terminated normally, using
select-frame-set-input-focus. Stack up all the recursive minibuffers on the
miniwindow where a new minibuffer is being opened. After the recursive edit,
switch the selected window away from the expired minibuffer's window.
(nth_minibuffer): New function.
(minibuffer-follows-selected-frame): Change from a DEFVAR_BOOL to a
DEFVAR_LISP.
* src/window.c (decode_next_window_args): Set *minibuf to w's mini-window's
content when that content is a minibuffer.
* src/window.h (minibuf_level) Declaration moved from here to lisp.h.
> martin
--
Alan Mackenzie (Nuremberg, Germany).
diff.20210109c.diff
Description: Text document
- Re: Stop frames stealing eachothers' minibuffers!, (continued)
- Re: Stop frames stealing eachothers' minibuffers!, martin rudalics, 2021/01/04
- Re: Stop frames stealing eachothers' minibuffers!, Alan Mackenzie, 2021/01/05
- Re: Stop frames stealing eachothers' minibuffers!, martin rudalics, 2021/01/05
- Re: Stop frames stealing eachothers' minibuffers!, Alan Mackenzie, 2021/01/07
- RE: Stop frames stealing eachothers' minibuffers!, Drew Adams, 2021/01/07
- Re: Stop frames stealing eachothers' minibuffers!, martin rudalics, 2021/01/07
- Re: Stop frames stealing eachothers' minibuffers!,
Alan Mackenzie <=
- Re: Stop frames stealing eachothers' minibuffers!, Stefan Monnier, 2021/01/09
- Re: Stop frames stealing eachothers' minibuffers!, Alan Mackenzie, 2021/01/10
- Re: Stop frames stealing eachothers' minibuffers!, martin rudalics, 2021/01/10
- Re: Stop frames stealing eachothers' minibuffers!, Alan Mackenzie, 2021/01/10
- Re: Stop frames stealing eachothers' minibuffers!, Stefan Monnier, 2021/01/10
- Re: Stop frames stealing eachothers' minibuffers!, martin rudalics, 2021/01/10
- Re: Stop frames stealing eachothers' minibuffers!, Alan Mackenzie, 2021/01/10
- Re: Stop frames stealing eachothers' minibuffers!, martin rudalics, 2021/01/10
- Re: Stop frames stealing eachothers' minibuffers!, Gregory Heytings, 2021/01/05
- Re: Stop frames stealing eachothers' minibuffers!, Stefan Monnier, 2021/01/05