From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Geoffrey Ferrari Newsgroups: gmane.emacs.help Subject: Re: elscreen and window-prev-buffers Date: Tue, 9 Oct 2012 02:15:23 -0700 (PDT) Message-ID: <18a4028b-120d-45ba-94ea-a042cf6cfd13@googlegroups.com> References: <9facc5e9-4ab9-49b6-bf1e-efee17ae8b82@googlegroups.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: ger.gmane.org 1349774413 16939 80.91.229.3 (9 Oct 2012 09:20:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 9 Oct 2012 09:20:13 +0000 (UTC) Cc: help-gnu-emacs@gnu.org 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 11:20:20 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 1TLVz9-000631-Uo for geh-help-gnu-emacs@m.gmane.org; Tue, 09 Oct 2012 11:20:20 +0200 Original-Received: from localhost ([::1]:34957 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TLVz3-0004CN-Ph for geh-help-gnu-emacs@m.gmane.org; Tue, 09 Oct 2012 05:20:13 -0400 Original-Received: by 10.224.31.20 with SMTP id w20mr14414402qac.2.1349774123393; Tue, 09 Oct 2012 02:15:23 -0700 (PDT) Original-Received: by 10.236.150.16 with SMTP id y16mr1987730yhj.8.1349774123368; Tue, 09 Oct 2012 02:15:23 -0700 (PDT) Original-Path: usenet.stanford.edu!l8no32504568qao.0!news-out.google.com!r17ni19qap.0!nntp.google.com!l8no32504567qao.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Original-Newsgroups: gnu.emacs.help In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=129.67.115.253; posting-account=k4cNIwoAAABm6KLXXxkyaqtaNZIecmJf Original-NNTP-Posting-Host: 129.67.115.253 User-Agent: G2/1.0 Injection-Date: Tue, 09 Oct 2012 09:15:23 +0000 Original-Xref: usenet.stanford.edu gnu.emacs.help:194807 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:87141 Archived-At: Michael, Thank you for taking the time to reply and explain - it helps to know that someone has looked at this problem. Is there an alternative to elscreen that you would recommend? Best wishes, Geoffrey On Monday, 8 October 2012 23:28:43 UTC+1, Michael Heerdegen wrote: > 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?