From: Juanma Barranquero <lekktu@gmail.com>
To: 16793@debbugs.gnu.org
Subject: bug#16793: window-state-put needs a live window
Date: Tue, 18 Feb 2014 17:20:04 +0100 [thread overview]
Message-ID: <CAAeL0SRmaOFk-kZPYXS7d0FDU-AxrdqbjXKvubJ_9DfzVfr6sw@mail.gmail.com> (raw)
Package: emacs
Version: 24.3.50
X-Debbugs-Cc: rudalics@gmx.at
There's a problem when restoring a frameset where "put"ing a window
state into the root window of a frame fails for some windows if the
frame is split (which is common enough).
It's easy to see the problem with
emacs -Q
C-x 2
C-x r f a
C-x r j a
=> "Error (frameset): #<window 6> is not a live window"
or
emacs -Q
;; eval this in *scratch*
(let (ws frw)
(split-window)
(setq frw (frame-root-window))
(setq ws (window-state-get frw))
(window-state-put ws frw))
=> "Lisp error: (error "#<window 6> is not a live window")"
Strictly speaking It's not a bug, because the docstring of
`window-state-put' says "Optional argument WINDOW must specify a live
window". But as the examples above show, it is less than useful to be
able to get the state of a window and not being able to put it again
into the same window.
In framesets, the problem arises because it's often the case that the
preferred frame to restore a window-state is the very same one the
window-state was saved from, particularly for saving/restoring in the
same session (as it happens with frameset-to-register /
jump-to-register). That minimizes flicker and simplifies dealing with
non-reused frames.
Martin suggests that frameset--restore should check that the root
window of the matching frame found is alive, and if not, discard that
frame and create a new one. That's doable, but it seems less than
optimal, from both a coding and UI perspective.
next reply other threads:[~2014-02-18 16:20 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-18 16:20 Juanma Barranquero [this message]
2014-02-18 17:09 ` bug#16793: window-state-put needs a live window Stefan Monnier
2014-02-18 17:20 ` Glenn Morris
2014-02-18 17:24 ` Glenn Morris
2014-02-18 18:28 ` Stefan Monnier
2014-02-18 18:37 ` Glenn Morris
2014-02-18 20:45 ` Stefan Monnier
2014-02-18 17:36 ` Juanma Barranquero
2014-02-18 18:29 ` Stefan Monnier
2014-02-18 19:04 ` martin rudalics
2014-02-18 21:18 ` Juanma Barranquero
2014-02-18 21:26 ` martin rudalics
2014-02-18 21:51 ` Juanma Barranquero
2014-02-19 10:02 ` martin rudalics
2014-02-19 11:09 ` Juanma Barranquero
2014-02-18 19:04 ` martin rudalics
2014-02-18 19:08 ` Juanma Barranquero
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=CAAeL0SRmaOFk-kZPYXS7d0FDU-AxrdqbjXKvubJ_9DfzVfr6sw@mail.gmail.com \
--to=lekktu@gmail.com \
--cc=16793@debbugs.gnu.org \
/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).