Subject: bug#16793: closed (Re: bug#16793: window-state-put needs a live window)

From: [email-masked] (GNU bug Tracking System)
Date: Wed, 19 Feb 2014 11:11:03 +0000

Your bug report

#16793: window-state-put needs a live window

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
16793: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16793
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#16793: window-state-put needs a live window
From: Juanma Barranquero <[email-masked]>
To: martin rudalics <[email-masked]>
Cc: [email-masked], Stefan Monnier <[email-masked]>
Date: Wed, 19 Feb 2014 12:09:24 +0100
List-Id: <debbugs-submit.debbugs.gnu.org>

> Installed (with the throw) in revision 116477.  You should be able to
> remove your workaround now.

Done. Thanks.

Subject: window-state-put needs a live window
From: Juanma Barranquero <[email-masked]>
To: Bug-Gnu-Emacs <[email-masked]>
Date: Tue, 18 Feb 2014 17:20:04 +0100
List-Id: <debbugs-submit.debbugs.gnu.org>

Package: emacs
Version: 24.3.50
X-Debbugs-Cc: [email-masked]

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.