bug#11556: 24.0.97; Strange behaviour of bury-buffer after desktop-read

bug#11556: 24.0.97; Strange behaviour of bury-buffer after desktop-read

[Tobias Bading]

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)

bug#11556: 24.0.97; Strange behaviour of bury-buffer after desktop-read

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 3847 bytes --]

 > 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.

This is accomplished by this form

	    (switch-to-buffer (car (buffer-list)))

in `desktop-read'.

 > 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.

What happens is this: The buffer section of .emacs.desktop lists buffers
"in same order as in buffer list".  Processing these in your case means
processing 1 then 2 then 3.  `desktop-restore-file-buffer', which is
implicitly called in this process, switches to 1, 2 and 3 in this order
in the selected window.  This means that the last buffer shown in the
window is 3.  After that, the above mentioned `switch-to-buffer' from
`desktop-read' switches to buffer 1.  Burying that buffer shows the last
buffer shown in the selected window which is 3 and not 2 as expected.

 > But some actions fix this, like switching
 > a buffer once using C-x b. Afterwards the bug is nowhere to be found.

Since the corruption happens once only when processing .emacs.desktop.

 > 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 :-).

The bug is obviously a regression with respect to Emacs 23.1 so we
should fix it.  One possible approach is to remove the buffer switching
done in `desktop-restore-file-buffer' which apparently should have the
sole reason to affect the buffer list while somehow preserving the
history of buffers that have been shown before calling `desktop-read'.
But I'm completely ignorant of desktop's handling of the buffer list
which involves some 14 calls to `bury-buffer' for restoring just three
buffers here.  If someone competent in this area could tell us how to
simplify this, I'd be all ears.

Eventually, we should handle this when restoring the windows from the
previous session but the question remains how to handle previously shown
buffers correctly when doing `desktop-read' in the middle of a session.

Meanwhile I can offer the attached brute force fix which kills the
individual history of all windows but should leave the buffer lists in
place.  Note that I have to manually bury the *Messages* buffer because
it's in the way as well when burying buffer 1.  All this is very ugly
but I can't think of a better fix without a rather complete rewrite of
desktop's handling of the buffer lists.

martin

[-- Attachment #2: desktop.diff --]
[-- Type: text/plain, Size: 932 bytes --]

*** lisp/desktop.el	2012-05-13 03:05:06 +0000
--- lisp/desktop.el	2012-05-27 10:52:53 +0000
***************
*** 1020,1025 ****
--- 1020,1037 ----
  			 (format ", %d to restore lazily"
  				 (length desktop-buffer-args-list))
  		       ""))
+ 	    ;; Bury the *Messages* buffer to not reshow it when burying
+ 	    ;; the buffer we switched to above.
+ 	    (when (buffer-live-p (get-buffer "*Messages*"))
+ 	      (bury-buffer "*Messages*"))
+ 	    ;; Clear all windows' previous and next buffers, these have
+ 	    ;; been corrupted by the `switch-to-buffer' calls in
+ 	    ;; `desktop-restore-file-buffer' (bug#1156).  This is a
+ 	    ;; brute force fix and should be replaced by a more subtle
+ 	    ;; strategy eventually.
+ 	    (walk-window-tree (lambda (window)
+ 				(set-window-prev-buffers window nil)
+ 				(set-window-next-buffers window nil)))
  	    t))
        ;; No desktop file found.
        (desktop-clear)

bug#11556: 24.0.97; Strange behaviour of bury-buffer after desktop-read

[Tobias Bading]

Hi Martin,

desktop.diff works fine for me, thank you.

> Eventually, we should handle this when restoring the windows from the
> previous session but the question remains how to handle previously shown
> buffers correctly when doing `desktop-read' in the middle of a session.


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.

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?

Kind regards,
Tobias

bug#11556: 24.0.97; Strange behaviour of bury-buffer after desktop-read

[martin rudalics]

 > 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