From debbugs-submit-bounces@debbugs.gnu.org Fri May 25 04:52:34 2012 Received: (at submit) by debbugs.gnu.org; 25 May 2012 08:52:34 +0000 Received: from localhost ([127.0.0.1]:42927 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SXqGA-0007Fi-5K for submit@debbugs.gnu.org; Fri, 25 May 2012 04:52:34 -0400 Received: from eggs.gnu.org ([208.118.235.92]:53523) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SXqFp-0007FC-P4 for submit@debbugs.gnu.org; Fri, 25 May 2012 04:52:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SXqEl-0004HY-HB for submit@debbugs.gnu.org; Fri, 25 May 2012 04:51:09 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:42939) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SXqEl-0004Gn-Dg for submit@debbugs.gnu.org; Fri, 25 May 2012 04:51:07 -0400 Received: from eggs.gnu.org ([208.118.235.92]:44697) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SXqEj-0006uk-Gc for bug-gnu-emacs@gnu.org; Fri, 25 May 2012 04:51:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SXqEc-0004De-GQ for bug-gnu-emacs@gnu.org; Fri, 25 May 2012 04:51:04 -0400 Received: from fmmailgate01.web.de ([217.72.192.221]:57424) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SXqEc-0004AF-7A for bug-gnu-emacs@gnu.org; Fri, 25 May 2012 04:50:58 -0400 Received: from moweb001.kundenserver.de (moweb001.kundenserver.de [172.19.20.114]) by fmmailgate01.web.de (Postfix) with ESMTP id 941481AEA1E25 for ; Fri, 25 May 2012 10:50:55 +0200 (CEST) Received: from [172.20.6.71] ([194.115.213.9]) by smtp.web.de (mrweb001) with ESMTPA (Nemesis) id 0MdLcJ-1SoXjo1SK3-00IVbB; Fri, 25 May 2012 10:50:55 +0200 Message-ID: <4FBF47E7.1000300@web.de> Date: Fri, 25 May 2012 10:50:47 +0200 From: Tobias Bading User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: bug-gnu-emacs@gnu.org Subject: 24.0.97; Strange behaviour of bury-buffer after desktop-read Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:rvsSoUBylKBqE0YIjXkLD5AF0B5feab9HPiR6BESD1b OmO0IdXcDaJcZb35TZ/jBDJYeoGd6qwaWq5M8n33JBYdloDmP+ 8jt60oPpPFR1FVgZgBnh5uAGjgi37MwQoQan6pIIShQwoOB8Fm Y3zuCQb1u63HWuc++kRFQiwbyxu2ASLfexxiX3YDb/Oxmz1Wtv YM89NzChOC3JSedI+xmFA== X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4-2.6 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 208.118.235.17 X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) 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 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) From debbugs-submit-bounces@debbugs.gnu.org Sun May 27 09:21:14 2012 Received: (at 11556) by debbugs.gnu.org; 27 May 2012 13:21:14 +0000 Received: from localhost ([127.0.0.1]:45346 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SYdPF-0005YP-II for submit@debbugs.gnu.org; Sun, 27 May 2012 09:21:14 -0400 Received: from mailout-de.gmx.net ([213.165.64.22]:54184) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1SYdPC-0005YC-Vw for 11556@debbugs.gnu.org; Sun, 27 May 2012 09:21:12 -0400 Received: (qmail invoked by alias); 27 May 2012 13:19:52 -0000 Received: from 62-47-61-97.adsl.highway.telekom.at (EHLO [62.47.61.97]) [62.47.61.97] by mail.gmx.net (mp024) with SMTP; 27 May 2012 15:19:52 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX181uFpEN/Q1IEj0YDncmxuDnYDQs4eW6jhmNlA9/i PoGC3B14IftIme Message-ID: <4FC22A00.3030608@gmx.at> Date: Sun, 27 May 2012 15:20:00 +0200 From: martin rudalics MIME-Version: 1.0 To: Tobias Bading Subject: Re: bug#11556: 24.0.97; Strange behaviour of bury-buffer after desktop-read References: <4FBF47E7.1000300@web.de> In-Reply-To: <4FBF47E7.1000300@web.de> Content-Type: multipart/mixed; boundary="------------080500040206030308060403" X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11556 Cc: 11556@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) This is a multi-part message in MIME format. --------------080500040206030308060403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit > 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 > > 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 --------------080500040206030308060403 Content-Type: text/plain; name="desktop.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="desktop.diff" *** 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) --------------080500040206030308060403-- From debbugs-submit-bounces@debbugs.gnu.org Sun May 27 12:18:37 2012 Received: (at 11556) by debbugs.gnu.org; 27 May 2012 16:18:37 +0000 Received: from localhost ([127.0.0.1]:45634 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SYgAu-00015z-Vp for submit@debbugs.gnu.org; Sun, 27 May 2012 12:18:37 -0400 Received: from fmmailgate03.web.de ([217.72.192.234]:56895) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SYgAZ-00015T-Mt for 11556@debbugs.gnu.org; Sun, 27 May 2012 12:18:34 -0400 Received: from moweb002.kundenserver.de (moweb002.kundenserver.de [172.19.20.108]) by fmmailgate03.web.de (Postfix) with ESMTP id 1A9F31B516379 for <11556@debbugs.gnu.org>; Sun, 27 May 2012 18:16:57 +0200 (CEST) Received: from [192.168.2.26] ([87.169.106.128]) by smtp.web.de (mrweb002) with ESMTPA (Nemesis) id 0Lecda-1SFb0A347K-00qQO9; Sun, 27 May 2012 18:16:56 +0200 Subject: Re: bug#11556: 24.0.97; Strange behaviour of bury-buffer after desktop-read Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Tobias Bading In-Reply-To: <4FC22A00.3030608@gmx.at> Date: Sun, 27 May 2012 18:16:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <77DBE6D1-BF5C-4728-AC11-0B0027C98230@web.de> References: <4FBF47E7.1000300@web.de> <4FC22A00.3030608@gmx.at> To: martin rudalics X-Mailer: Apple Mail (2.1084) X-Provags-ID: V02:K0:SK7r76CZGnnw6fV/xrUL/KUS/deV7gMUv0/KTuKP7B0 Kv986mjwdCwajy6zUmW3JspTpiCJtZQCk7DuAynE2QtRaL5/GB QpbDciBbVP+4Y0OVKBiWspVC1uTSqhPWnvpZjMAKhcM27ZdFsW 9i5/JVXmq/S0QQn9sMf1rHDMpvYKQbE9rZShoKQwX8fyrieTLq SiABlAbefzLiV/cjr0h5A== X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11556 Cc: 11556@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) 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 From debbugs-submit-bounces@debbugs.gnu.org Mon May 28 06:27:53 2012 Received: (at 11556-done) by debbugs.gnu.org; 28 May 2012 10:27:53 +0000 Received: from localhost ([127.0.0.1]:46245 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SYxB2-0000Qj-Nq for submit@debbugs.gnu.org; Mon, 28 May 2012 06:27:53 -0400 Received: from mailout-de.gmx.net ([213.165.64.23]:36613) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1SYxAz-0000QW-Ty for 11556-done@debbugs.gnu.org; Mon, 28 May 2012 06:27:50 -0400 Received: (qmail invoked by alias); 28 May 2012 10:26:26 -0000 Received: from 62-47-38-14.adsl.highway.telekom.at (EHLO [62.47.38.14]) [62.47.38.14] by mail.gmx.net (mp069) with SMTP; 28 May 2012 12:26:26 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX195vS4dWe557TuJYicRKtaMvm+WexEn5jIL3q9wk6 abUMLWskCxcvML Message-ID: <4FC352D2.2090805@gmx.at> Date: Mon, 28 May 2012 12:26:26 +0200 From: martin rudalics MIME-Version: 1.0 To: 11556-done@debbugs.gnu.org Subject: Re: bug#11556: 24.0.97; Strange behaviour of bury-buffer after desktop-read References: <4FBF47E7.1000300@web.de> <4FC22A00.3030608@gmx.at> <77DBE6D1-BF5C-4728-AC11-0B0027C98230@web.de> In-Reply-To: <77DBE6D1-BF5C-4728-AC11-0B0027C98230@web.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11556-done Cc: Tobias Bading X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > 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 From unknown Sun Sep 07 22:57:46 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Mon, 25 Jun 2012 11:24:07 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator