From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Angelo Graziosi Newsgroups: gmane.emacs.devel Subject: Re: Buffers relative order Date: Tue, 21 Jun 2011 19:59:04 +0200 Message-ID: <4E00DBE8.1070309@alice.it> References: <4DFFC6A3.5010506@alice.it> <4E009EC8.90201@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1308683969 22065 80.91.229.12 (21 Jun 2011 19:19:29 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 21 Jun 2011 19:19:29 +0000 (UTC) Cc: emacs To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jun 21 21:19:25 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QZ6Tq-0007Dt-Hq for ged-emacs-devel@m.gmane.org; Tue, 21 Jun 2011 21:19:22 +0200 Original-Received: from localhost ([::1]:55379 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QZ6Tp-0002qF-9e for ged-emacs-devel@m.gmane.org; Tue, 21 Jun 2011 15:19:21 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:41453) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QZ5EN-0004jR-8Q for emacs-devel@gnu.org; Tue, 21 Jun 2011 13:59:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QZ5EH-000110-Oz for emacs-devel@gnu.org; Tue, 21 Jun 2011 13:59:19 -0400 Original-Received: from smtp205.alice.it ([82.57.200.101]:55230) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QZ5EH-00010s-5N for emacs-devel@gnu.org; Tue, 21 Jun 2011 13:59:13 -0400 Original-Received: from [192.168.1.101] (95.245.63.244) by smtp205.alice.it (8.5.124.08) id 4DE6347501F14A03; Tue, 21 Jun 2011 19:59:09 +0200 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 In-Reply-To: <4E009EC8.90201@gmx.at> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 82.57.200.101 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:140795 Archived-At: Il 21/06/2011 15.38, martin rudalics ha scritto: > > With this new behavior, after a few start/exit Emacs, it is difficult to > > work, the order is lost (header files are "far" from .c/.cxx etc.) > > > > Is this a something with which we will have to do in Emacs24? > > Not necessarily. I can easily restore the old behavior. The best thing to do! :) > > The modeline functions currently operate on window local buffer lists > which allow to navigate primarily the buffers shown in that specific > window first. Only when you arrive at one of the ends of that list a > buffer from the frame local or global buffer list is chosen. > > If you have just one window in your session, the results should be > identic for the next session. If you have more than one window, the The steps I flagged in my OP are done in a single frame and in a single window... every new session shows different results A B C D <---- previous C B A D <---- previous ABCD DBAC (SINGLE frame and window!) > results will differ, since window local buffer lists are currently not > yet saved and restored. > > IIUC, however, frame local buffer lists are not handled by desktop > either. So your new session will already show different behaviors if > you used more than one frame in the previous session. As I stated above, I have a single frame and a single window, at each session ((desktop-save-mode t)), I get a different order.. In my real work (about 20 buffers per session), I cannot work with this behavior.. I have to use a speedbar or reinstall an older version of trunk (say <= 10 June 2011). If there is an option I can set in my .emacs file to restore the behavior Emacs has always got, I will greatly appreciate... Thanks, Angelo.