From: martin rudalics <rudalics@gmx.at>
To: Juri Linkov <juri@linkov.net>
Cc: 54028@debbugs.gnu.org
Subject: bug#54028: Window is not a valid window
Date: Sat, 19 Feb 2022 10:38:45 +0100 [thread overview]
Message-ID: <3edffa06-2c6e-3fe0-07bd-ea880ad6652f@gmx.at> (raw)
In-Reply-To: <86zgmplblo.fsf@mail.linkov.net>
> Thanks, it doesn't fail anymore, but wasn't the problem
> somewhere in the invalid window state?
No. The sequence of events leading to the bug is the following:
'window-state-put' has
;; Work on the windows of a temporary buffer to make sure that
;; splitting proceeds regardless of any buffer local values of
;; `window-size-fixed'. Release that buffer after the buffers of
;; all live windows have been set by `window--state-put-2'.
(with-temp-buffer
(set-window-buffer window (current-buffer))
(window--state-put-1 state window nil totals pixelwise)
(window--state-put-2 ignore pixelwise))
When this calls 'window--state-put-2', the window's buffer is *temp*.
'window--state-put-2' has:
;; We don't want to raise an error in case the buffer does
;; not exist anymore, so we switch to a previous one and
;; save the window with the intention of deleting it later
;; if possible.
(switch-to-prev-buffer window)
(push window window-state-put-stale-windows)))))))
Here, since window has no previous buffer, *temp* remains that window's
buffer. Now *temp* gets killed when the 'with-temp-buffer' form exits
and, since its window is deletable, that window simply gets deleted via
‘kill-buffer’. Back in 'window-state-put' we do
(while window-state-put-stale-windows
(let ((window (pop window-state-put-stale-windows)))
(when (eq (window-deletable-p window) t)
(delete-window window))))
and here the window is no more valid because it has been deleted in
the meantime.
So AFAICT we start with a valid window state 'window-state-put' can't
handle. I have no idea why this didn't hit us before. Maybe, because
such windows usually have a previous buffer 'switch-to-prev-buffer' can
switch to.
>> I have no idea whether the state is restored as intended, though.
>
> Is it possible to find what window was invalid in this window state?
There is none as I tried to explain above. The question is rather
whether the restored state resembles the saved state satisfactorily.
But that only the OP can tell.
martin
next prev parent reply other threads:[~2022-02-19 9:38 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-16 18:50 bug#54028: Window is not a valid window Juri Linkov
2022-02-17 10:06 ` martin rudalics
2022-02-17 17:34 ` Juri Linkov
2022-02-19 9:38 ` martin rudalics [this message]
2022-02-21 9:07 ` martin rudalics
2022-02-21 12:30 ` Eli Zaretskii
2022-02-21 16:50 ` martin rudalics
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3edffa06-2c6e-3fe0-07bd-ea880ad6652f@gmx.at \
--to=rudalics@gmx.at \
--cc=54028@debbugs.gnu.org \
--cc=juri@linkov.net \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.