emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#16749: closed (More informative error when restori


From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#16749: closed (More informative error when restoring frameset with killed buffer)
Date: Sat, 15 Feb 2014 04:40:02 +0000

Your message dated Sat, 15 Feb 2014 05:38:13 +0100
with message-id <address@hidden>
and subject line Re: bug#16749: More informative error when restoring frameset 
with killed buffer
has caused the debbugs.gnu.org bug report #16749,
regarding More informative error when restoring frameset with killed buffer
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
16749: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16749
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: More informative error when restoring frameset with killed buffer Date: Fri, 14 Feb 2014 01:52:55 -0500 User-agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/)
Package: emacs
Version: 24.3.50
Severity: minor

Current trunk on GNU/Linux under X.

emacs -Q
C-x C-f 1
C-x r f a
C-x k 1 RET
C-x r j a
   -> jump-to-register: Wrong type argument: stringp, nil

I see that the commentary of frameset.el says it does not restore killed
buffers. That's fine, but a more informative error message would be
better ("Buffer 1 has been killed" or somesuch).



--- End Message ---
--- Begin Message --- Subject: Re: bug#16749: More informative error when restoring frameset with killed buffer Date: Sat, 15 Feb 2014 05:38:13 +0100
On Fri, Feb 14, 2014 at 7:52 AM, Glenn Morris <address@hidden> wrote:

> I see that the commentary of frameset.el says it does not restore killed
> buffers.

That comment refers to window-state-put's functionality, but this bug
is just that I forgot to check that the buffer was live before trying
to restore the point. Fixed now.

> That's fine, but a more informative error message would be
> better ("Buffer 1 has been killed" or somesuch).

At that point, the saved state does not contain the buffer name, just
a marker that points nowhere, so we cannot say "Buffer XXX was killed"
because we don't know that it was called XXX. (Well, strictly speaking
the buffer name is probably somewhere inside frameset-states, but I
don't think digging that info is worth the effort.)

> PS Perhaps it should not stop with an error on encountering a dead
> buffer, but should continue restoring as much as it can, then give a
> summary message/error about dead buffer(s) at the end.

It already restores as much as it can, because that's what
window-state-put does. Dead buffers are ignored and their windows get
another buffer. The current bug does not happen when restoring the
window/buffer, just the selected buffer and point at the end of
jump-to-register.

Also, when using frame-configuration-to-register, jumping to a saved
frame configuration for a deleted frame fails silently. I don't think
jump-to-frameset should be noisier.

   J


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]