From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Michael Heerdegen Newsgroups: gmane.emacs.help Subject: Re: elscreen and window-prev-buffers Date: Tue, 09 Oct 2012 00:28:38 +0200 Message-ID: <87haq4ioo9.fsf@web.de> References: <9facc5e9-4ab9-49b6-bf1e-efee17ae8b82@googlegroups.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1349735325 24854 80.91.229.3 (8 Oct 2012 22:28:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 8 Oct 2012 22:28:45 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Tue Oct 09 00:28:52 2012 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TLLoh-0004Yo-N5 for geh-help-gnu-emacs@m.gmane.org; Tue, 09 Oct 2012 00:28:51 +0200 Original-Received: from localhost ([::1]:55686 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TLLob-0001FJ-GQ for geh-help-gnu-emacs@m.gmane.org; Mon, 08 Oct 2012 18:28:45 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:47084) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TLLoW-0001Ey-3O for help-gnu-emacs@gnu.org; Mon, 08 Oct 2012 18:28:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TLLoU-0002KX-SS for help-gnu-emacs@gnu.org; Mon, 08 Oct 2012 18:28:40 -0400 Original-Received: from mout.web.de ([212.227.17.11]:50722) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TLLoU-0002K7-Iv for help-gnu-emacs@gnu.org; Mon, 08 Oct 2012 18:28:38 -0400 Original-Received: from drachen.dragon ([89.204.130.248]) by smtp.web.de (mrweb001) with ESMTPSA (Nemesis) id 0Lb1rd-1Tnqws2Cld-00kSc8; Tue, 09 Oct 2012 00:28:36 +0200 Mail-Followup-To: help-gnu-emacs@gnu.org In-Reply-To: <9facc5e9-4ab9-49b6-bf1e-efee17ae8b82@googlegroups.com> (Geoffrey Ferrari's message of "Sun, 7 Oct 2012 03:44:38 -0700 (PDT)") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux) X-Provags-ID: V02:K0:75eveIU9FXLQkdlSVoYXT3vuIGl8Trf9l0Ver4XMmA4 y7bZtKSmfygWsIHTfR0vUC5aLEToptrFfeG1rzGipe1rN4aiu0 CDouIUMfeOJSUs13Gib/O2C8huGQiaY6ibgFl7FlMthvqVyBcy cMpAR+0+ARRNnVhXb2uY+NKW7AFM2mDcVlm7lTEIYbX7CpJ1Po kz/zSFioqTEpB7Wh1vSFhOZfShG3/SZVoJvhIcKY7g= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 212.227.17.11 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:87139 Archived-At: Hi Geoffrey, I'm a former user of elscreen. Yes, it's a bug, I saw that too. I debugged it, but fixing it is not trivial. Background: The problem are the calls to `elscreen-goto-internal' in `elscreen-get-screen-to-name-alist'. Screens internally use window configurations. These are a primitive data type. You are not able to "look inside them" if you don't apply them. That's the underlying problem. Sorry I can't help more. I only can provide a trivial patch that fixes the problem for the price that the names of the screens disappear in the header-line. I now have given up using elscreen because of problems like that. That winner-mode doesn't work well with elscreen was another one. Regards, Michael. Geoffrey Ferrari writes: > I'm seeing some strange interaction between elscreen > (elscreen-20120413.1107 from marmalade repo) and window-prev-buffers. > > First let me illustrate the normal, expected behaviour. Suppose I > start emacs with emacs -Q. At the start, the result of eval-ing > (window-prev-buffers) is nil. Then I open file1.txt using find-file > and (window-prev-buffers) returns a list whose sole element is the > scratch buffer. Then I open file2.txt and it returns a list of > file1.txt and the scratch buffer. This is good behaviour because when > I kill the file2.txt buffer, I see file1.txt again, and then when I > kill file1.txt, I return to the scratch buffer. I return to files in > the order in which I opened them. > > Now suppose I activate elscreen (which automatically creates screen > #0) and then create a new screen, which becomes screen #1. At this > starting point, (window-prev-buffers) returns a list whose sole > element is the scratch buffer. Then, when I open file1.txt, it returns > a list of the scratch buffer and the buffer showing file1.txt. Then > when I open file2.txt, it returns a list of the scratch buffer, then > file1.txt's buffer, then file2.txt's buffer. Now, if I kill file2.txt, > the window automatically redisplays the scratch buffer, not > file1.txt. I think this is bad behaviour - my files are not > redisplayed in the order in which I opened them. > > Clearly, the behaviour here is different. For some reason, with > elscreen and a new screen, the scratch buffer is always kept as the > first element of (window-prev-buffers), and opening a new buffer > appends it to (window-prev-buffers) *after* the scratch buffer. > > Has anyone else noticed this behaviour? Is there anything that can be > done to improve it?