emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Buffers relative order


From: Angelo Graziosi
Subject: Re: Buffers relative order
Date: Tue, 21 Jun 2011 19:59:04 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]