--- Begin Message ---
|
Subject: |
29.0.50; wrong-type-argument in minibuffer-only frames |
|
Date: |
Fri, 27 May 2022 16:09:13 -0400 |
Package: Emacs
Version: 29.0.50
src/emacs -Q --eval '(setq default-frame-alist `((minibuffer . nil)))'
Stays "frozen" because of a wrong-type-argument error in
`Fset_frame_selected_window` on `CHECK_LIVE_WINDOW (window);`.
The patch below seems to "fix" it, but I must admit that I don't really
understand this code (see for example the FIXME comment in the patch).
Does someone know what is the user-level behavior we're trying to
obtain here?
It seems that this comes from Alan's commit dfa3e6f424b20fe27d904.
Stefan
diff --git a/src/frame.c b/src/frame.c
index 252dc591bfa..dc55004b193 100644
--- a/src/frame.c
+++ b/src/frame.c
@@ -1576,8 +1576,14 @@ do_switch_frame (Lisp_Object frame, int track, int
for_deletion, Lisp_Object nor
to a different window, the most recently used one, unless there is a
valid active minibuffer in the mini-window. */
if (EQ (f->selected_window, f->minibuffer_window)
+ /* FIXME: Can this test ever fail? I.e. can 'minibuffer_window'
+ ever contain a non-mini-buffer (and if so, should we care here)? */
&& NILP (Fminibufferp (XWINDOW (f->minibuffer_window)->contents, Qt)))
- Fset_frame_selected_window (frame, call1 (Qget_mru_window, frame), Qnil);
+ {
+ Lisp_Object w = call1 (Qget_mru_window, frame);
+ if (!NILP (w)) /* Can be nil in minibuffer-only frames. */
+ Fset_frame_selected_window (frame, w, Qnil);
+ }
Fselect_window (f->selected_window, norecord);
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#55684: 29.0.50; wrong-type-argument in minibuffer-only frames |
|
Date: |
Sat, 28 May 2022 10:22:24 -0400 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) |
>> @@ -1576,8 +1576,14 @@ do_switch_frame (Lisp_Object frame, int track, int
>> for_deletion, Lisp_Object nor
>> to a different window, the most recently used one, unless there is a
>> valid active minibuffer in the mini-window. */
>> if (EQ (f->selected_window, f->minibuffer_window)
>> + /* FIXME: Can this test ever fail? I.e. can 'minibuffer_window'
>> + ever contain a non-mini-buffer (and if so, should we care
>> here)? */
>> && NILP (Fminibufferp (XWINDOW (f->minibuffer_window)->contents, Qt)))
>
> Yes, the test can fail. The buffer in the mini-window might be (the
> non-active) minibuffer 0. The meaning of the argument Qt is to return
> non-nil only for active minibuffers.
Ah, indeed I missed this detail. I guess that mini window can
also hold the echo area. Thanks for the explanation,
Stefan
--- End Message ---