From: Alan Mackenzie <acm@muc.de>
To: Eli Zaretskii <eliz@gnu.org>
Cc: rudalics@gmx.at, 56305@debbugs.gnu.org, monnier@iro.umontreal.ca,
acm@muc.de
Subject: bug#56305: 29.0.50; 'yes-or-no-p' deselects minibuffer frame
Date: Wed, 6 Jul 2022 17:04:40 +0000 [thread overview]
Message-ID: <YsXAqHnCkG45OuO5@ACM> (raw)
In-Reply-To: <83zghn7ckd.fsf@gnu.org>
Hello, Eli, Martin and Stefan.
On Tue, Jul 05, 2022 at 19:24:02 +0300, Eli Zaretskii wrote:
> > Date: Tue, 5 Jul 2022 15:59:00 +0000
> > Cc: rudalics@gmx.at, monnier@iro.umontreal.ca, 56305@debbugs.gnu.org
> > From: Alan Mackenzie <acm@muc.de>
> > > > After typing C-x C-c, rather than exiting, this particular Emacs
> > > > prompts:
> > > > "Active processes exist; kill them and exit anyway? (yes or no) "
> > > > on MBF and it opens a window *Process List* on NF.
> > > Sounds right to me: the frame where Emacs presents some important
> > > information has focus. If you think this is wrong, please tell why.
> > Well, I don't have a firm opinion on this, but yes-or-no-p is an active
> > function, here. We always leave the minibuffer as the selected window
> > for this function, certainly when we've a normal minibuffer in the frame.
> > Why should it be different when we've got a minibuffer-only frame?
> > Also, the mechanism by which NF gets the focus in the bug scenario
> > appears to be random. When the focus starts out in NF and we do C-x C-c,
> > the focus moves to MBF. This is inconsistent.
> > The place where the randomness takes effect is the
> > Fredirect_frame_focus (gfocus, frame);
> > in do_switch_frame I drew attention to yesterday.
> Do you have a suggestion for a change there to improve the behavior?
I do now. I think we should expunge the entire section of code.
I've spent several hours trying to make sense of it, and failed. The
code section is 30 years old, and Jim Blandy's comment (from 1992)
suggests that the code was inserted to enable movement between frames
using other-window.
That code was written a few months before the new function other-window
was first committed. The #ifdef 0 made its appearance in 1993, it being
written by Karl Heuer.
My feeling is that the code section became redundant in the early 1990s,
immediately after the introduction of other-frame, but lived on since
nobody could be sure it wasn't needed.
As I said, I don't understand the code section, and my Emacs appears to
run OK without it. I think we should get rid of it. Alternatively, if
somebody else can see a purpose for it, maybe we could amend it to leave
that purpose intact and solve Martin's bug #56305 at the same time.
Here's the patch (based on master) I propose should be committed,
possibly experimentally. Comments would we welcome:
diff --git a/src/frame.c b/src/frame.c
index c21461d49f..f9e4b2a0e2 100644
--- a/src/frame.c
+++ b/src/frame.c
@@ -1477,59 +1477,6 @@ do_switch_frame (Lisp_Object frame, int track, int for_deletion, Lisp_Object nor
else if (f == sf)
return frame;
- /* If a frame's focus has been redirected toward the currently
- selected frame, we should change the redirection to point to the
- newly selected frame. This means that if the focus is redirected
- from a minibufferless frame to a surrogate minibuffer frame, we
- can use `other-window' to switch between all the frames using
- that minibuffer frame, and the focus redirection will follow us
- around. */
-#if 0
- /* This is too greedy; it causes inappropriate focus redirection
- that's hard to get rid of. */
- if (track)
- {
- Lisp_Object tail;
-
- for (tail = Vframe_list; CONSP (tail); tail = XCDR (tail))
- {
- Lisp_Object focus;
-
- if (!FRAMEP (XCAR (tail)))
- emacs_abort ();
-
- focus = FRAME_FOCUS_FRAME (XFRAME (XCAR (tail)));
-
- if (FRAMEP (focus) && XFRAME (focus) == SELECTED_FRAME ())
- Fredirect_frame_focus (XCAR (tail), frame);
- }
- }
-#else /* ! 0 */
- /* Instead, apply it only to the frame we're pointing to. */
-#ifdef HAVE_WINDOW_SYSTEM
- if (track && FRAME_WINDOW_P (f) && FRAME_TERMINAL (f)->get_focus_frame)
- {
- Lisp_Object focus, gfocus;
-
- gfocus = FRAME_TERMINAL (f)->get_focus_frame (f);
- if (FRAMEP (gfocus))
- {
- focus = FRAME_FOCUS_FRAME (XFRAME (gfocus));
- if (FRAMEP (focus) && XFRAME (focus) == SELECTED_FRAME ())
- /* Redirect frame focus also when FRAME has its minibuffer
- window on the selected frame (see Bug#24500).
-
- Don't do that: It causes redirection problem with a
- separate minibuffer frame (Bug#24803) and problems
- when updating the cursor on such frames.
- || (NILP (focus)
- && EQ (FRAME_MINIBUF_WINDOW (f), sf->selected_window))) */
- Fredirect_frame_focus (gfocus, frame);
- }
- }
-#endif /* HAVE_X_WINDOWS */
-#endif /* ! 0 */
-
if (!for_deletion && FRAME_HAS_MINIBUF_P (sf))
resize_mini_window (XWINDOW (FRAME_MINIBUF_WINDOW (sf)), 1);
--
Alan Mackenzie (Nuremberg, Germany).
next prev parent reply other threads:[~2022-07-06 17:04 UTC|newest]
Thread overview: 83+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-29 17:54 bug#56305: 29.0.50; 'yes-or-no-p' deselects minibuffer frame martin rudalics
2022-06-29 19:10 ` Eli Zaretskii
2022-06-30 10:35 ` Alan Mackenzie
2022-06-30 20:32 ` Alan Mackenzie
2022-07-02 11:38 ` Alan Mackenzie
2022-07-03 8:16 ` martin rudalics
2022-07-03 16:09 ` Alan Mackenzie
2022-07-03 16:17 ` Eli Zaretskii
2022-07-04 19:10 ` Alan Mackenzie
2022-07-04 19:21 ` Eli Zaretskii
2022-07-04 19:43 ` Alan Mackenzie
2022-07-05 2:29 ` Eli Zaretskii
2022-07-05 15:59 ` Alan Mackenzie
2022-07-05 16:24 ` Eli Zaretskii
2022-07-05 17:09 ` Alan Mackenzie
2022-07-06 17:04 ` Alan Mackenzie [this message]
2022-07-06 17:29 ` Eli Zaretskii
2022-07-06 18:16 ` Alan Mackenzie
2022-07-06 18:34 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-06 18:58 ` Andreas Schwab
2022-07-06 19:05 ` Alan Mackenzie
2022-07-06 19:09 ` Andreas Schwab
2022-07-06 19:22 ` Alan Mackenzie
2022-07-07 17:25 ` Alan Mackenzie
2022-07-07 18:57 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-08 21:03 ` Alan Mackenzie
2022-07-09 2:15 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-07 7:55 ` martin rudalics
2022-07-07 9:12 ` Alan Mackenzie
2022-07-08 7:01 ` martin rudalics
2022-07-08 10:55 ` Alan Mackenzie
2022-07-08 11:55 ` Eli Zaretskii
2022-07-08 18:31 ` Alan Mackenzie
2022-07-09 8:36 ` martin rudalics
2022-07-08 21:45 ` Gregory Heytings
2022-07-09 8:35 ` martin rudalics
2022-07-09 10:57 ` Alan Mackenzie
2022-07-10 8:07 ` martin rudalics
2022-07-10 11:34 ` Alan Mackenzie
2022-07-10 11:47 ` Eli Zaretskii
2022-07-10 12:41 ` Alan Mackenzie
2022-07-10 13:01 ` Eli Zaretskii
2022-07-10 16:13 ` Drew Adams
2022-07-10 16:55 ` Alan Mackenzie
2022-07-11 7:45 ` martin rudalics
2022-07-11 11:12 ` Eli Zaretskii
2022-07-12 7:33 ` martin rudalics
2022-07-12 16:02 ` Eli Zaretskii
2022-07-11 16:22 ` Alan Mackenzie
2022-07-11 16:43 ` Eli Zaretskii
2022-07-11 17:15 ` Alan Mackenzie
2022-07-11 17:33 ` Eli Zaretskii
2022-07-11 17:34 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-11 20:09 ` Alan Mackenzie
2022-07-11 17:06 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-11 20:01 ` Alan Mackenzie
2022-07-12 7:35 ` martin rudalics
2022-07-12 14:56 ` Drew Adams
2022-07-16 7:06 ` martin rudalics
2022-07-16 20:34 ` Alan Mackenzie
2022-07-18 7:36 ` martin rudalics
2022-07-18 14:44 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-19 8:09 ` martin rudalics
2022-07-19 16:04 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-16 23:39 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-17 11:29 ` Alan Mackenzie
2022-07-17 14:03 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-17 15:06 ` Alan Mackenzie
2022-07-18 7:37 ` martin rudalics
2022-07-18 14:58 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-18 15:58 ` Eli Zaretskii
2022-07-18 16:12 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-18 16:50 ` Eli Zaretskii
2022-07-19 20:48 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-20 12:17 ` Eli Zaretskii
2022-07-20 14:54 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-20 16:02 ` Eli Zaretskii
2022-07-21 15:07 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-21 15:58 ` Eli Zaretskii
2022-07-19 8:09 ` martin rudalics
2022-07-07 15:54 ` Alan Mackenzie
2022-07-04 19:46 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-04 19:59 ` Alan Mackenzie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YsXAqHnCkG45OuO5@ACM \
--to=acm@muc.de \
--cc=56305@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=monnier@iro.umontreal.ca \
--cc=rudalics@gmx.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).