GNU bug report logs -
#11556
24.0.97; Strange behaviour of bury-buffer after desktop-read
Previous Next
Reported by: Tobias Bading <tbading <at> web.de>
Date: Fri, 25 May 2012 08:53:01 UTC
Severity: normal
Found in version 24.0.97
Done: martin rudalics <rudalics <at> gmx.at>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your message dated Mon, 28 May 2012 12:26:26 +0200
with message-id <4FC352D2.2090805 <at> gmx.at>
and subject line Re: bug#11556: 24.0.97; Strange behaviour of bury-buffer after desktop-read
has caused the debbugs.gnu.org bug report #11556,
regarding 24.0.97; Strange behaviour of bury-buffer after desktop-read
to be marked as done.
(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)
--
11556: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11556
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
Hi,
I recently switched from Emacs 23 to the current version on the emacs-24
branch (r108014) and bumped into a strange behaviour of bury-buffer at
the start of a session. I'm using desktop.el and (global-set-key "\C-xy"
'bury-buffer) in .emacs (because I have a bad memory and like to bury
stuff ;-). Every time I start Emacs, I see the correct buffer, i.e. the
one I used before I closed Emacs previously. I edit that buffer a bit
and bury it. In my case, bury-buffer switches to the wrong buffer.
Instead of switching to the buffer next in line (so to speak),
bury-buffer switches to what seems to be the last buffer in the list of
all buffers.
Here's a little example in form of a "emacs -Q" recipe:
3 C-x C-s 3 RET
C-x b 2 RET
2 C-x C-s 2 RET
C-x b 1 RET
1 C-x C-s 1 RET
M-x desktop-save <filename>
This should leave you with with three saved buffers in the order 1-2-3
and a desktop file. C-x C-b should be able to confirm the buffer order.
Now close Emacs, start a fresh one and M-x desktop-read your desktop
file. You should see buffer 1. So far, so good. Now M-x bury-buffer. I'd
expect to see buffer 2 now, instead Emacs switched to buffer 3. If you
C-x C-b now, you'll see that the buffer list says that buffer 2 is up
front, although you're staring at buffer 3. This bug hits you only at
the very beginning of a session. I can continue to bury buffers using
C-x y and end up with buffers apparently from the end of the buffer
list, instead of from the top. But some actions fix this, like switching
a buffer once using C-x b. Afterwards the bug is nowhere to be found.
The last few days I started work with a strange
I-could-swear-that-wasnt-the-file-I-was-working-on-yesterday-before-I-went-home
feeling :-D. Any ideas on how to get rid of that feeling are very
welcome :-).
Kind regards,
Tobias
---
In GNU Emacs 24.0.97.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.20.1)
of 2012-05-25 on pen-bld-274apcl
Windowing system distributor `The X.Org Foundation', version 11.0.10706000
Configured using:
`configure '--prefix=...''
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: POSIX
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: de_DE.utf8
value of $LANG: en_US.utf8
value of $XMODIFIERS: nil
locale-coding-system: utf-8-unix
default enable-multibyte-characters: t
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Load-path shadows:
None found.
Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail regexp-opt rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils time-date tooltip ediff-hook
vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image
fringe lisp-mode register page menu-bar rfn-eshadow timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese hebrew greek romanian slovak czech european ethiopic
indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple
abbrev minibuffer loaddefs button faces cus-face files text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process dbusbind
dynamic-setting system-font-setting font-render-setting move-toolbar gtk
x-toolkit x multi-tty emacs)
[Message part 3 (message/rfc822, inline)]
> desktop.diff works fine for me, thank you.
Committed in revision 108018 of the release branch.
> What to expect from desktop-read when used in the middle of a session?
> Good question. I never use it that way, because I tend to spam my one
> and only session with lots of buffers ;-). However, other more
> organized people might use multiple desktop files. They would probably
> want desktop-read to behave as in Emacs 23, whatever that behaviour
> exactly was.
I don't use desktop but wonder what should happen when, for example, a
buffer read by `desktop-read' exists already. Should it move to the
front of the buffer lists or stay where it was before?
> The "If no desktop file is found, clear the desktop
> [...]" part in the doc-string of desktop-read sounds odd to me. Why
> would the function want to clear the desktop if it doesn't find a
> desktop file, but perform some sort of a merge operation with the
> current session (instead of a replace) if one is found?
Looks odd. Anyone who wants to clear the desktop could do this by
calling `desktop-clear'.
I'm looking for a kind soul to work on integrating window handling into
desktop.
martin
This bug report was last modified 13 years and 77 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.