--- Begin Message ---
|
Subject: |
24.0.97; Strange behaviour of bury-buffer after desktop-read |
|
Date: |
Fri, 25 May 2012 10:50:47 +0200 |
|
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 |
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)
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#11556: 24.0.97; Strange behaviour of bury-buffer after desktop-read |
|
Date: |
Mon, 28 May 2012 12:26:26 +0200 |
> 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
--- End Message ---