Buffers relative order

Buffers relative order

[Angelo Graziosi]

With recent changes in trunk, it seems that buffers relative order is 
different between sessions (desktop save on).

Suppose I start Emacs without any desktop file, and visit some buffer:

C-x C-f A
C-x C-f B
C-x C-f C
C-x C-f D

So D is what I see in the frame. Now suppose I click mouse-1 (previous 
buffer) on the buffer name in status bar. I get:

mouse-1 -->  C
mouse-1 -->  B
mouse-1 -->  A
mouse-1 -->  Scratch
mouse-1 -->  Messages
mouse-1 -->  D

Still D in the frame...

   A  B  C  D
      <---- previous

If now I save desktop and exit, when restart Emacs I find

D
mouse-1 -->  A
mouse-1 -->  B
mouse-1 -->  C
mouse-1 -->  Scratch
mouse-1 -->  Messages
mouse-1 -->  D

   C  B  A  D
      <---- previous

This is a different (cyclic) sequence. If one exits Emacs from Scratch 
or Messages or from another buffer, one gets a permutation of ABCD, say 
DBAC...

Now, usually I want to preserve the relative order of buffers I am 
working on, mainly because they are "linked" with some logic (.c,.cxx,.h 
project 1; .f90 proj. 2; .sh proj. 3 etc.)

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?


Ciao,
Angelo.

Re: Buffers relative order

[martin rudalics]

 > 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 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
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.

martin

Re: Buffers relative order

[Angelo Graziosi]

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.

Re: Buffers relative order

[martin rudalics]

 > If there is an option I can set in my .emacs file to restore the
 > behavior Emacs has always got, I will greatly appreciate...

Let's see if the problem is really with the redefinition of
`next-buffer' and `previous-buffer'.  Please, add the two following
functions two your .emacs and tell me whether the old behavior gets
restored.

Thanks, martin


(defun next-buffer ()
   "Switch to the next buffer in cyclic order."
   (interactive)
   (let ((buffer (current-buffer)))
     (switch-to-buffer (other-buffer buffer t))
     (bury-buffer buffer)))

(defun previous-buffer ()
   "Switch to the previous buffer in cyclic order."
   (interactive)
   (switch-to-buffer (last-buffer (current-buffer) t)))

Re: Buffers relative order

[Angelo Graziosi]

Il 22/06/2011 14.33, martin rudalics ha scritto:
>  > If there is an option I can set in my .emacs file to restore the
>  > behavior Emacs has always got, I will greatly appreciate...
>
> Let's see if the problem is really with the redefinition of
> `next-buffer' and `previous-buffer'. Please, add the two following
> functions two your .emacs and tell me whether the old behavior gets
> restored.

Oh yes! it seems the same original behavior!

Thanks,
Angelo.

>
> Thanks, martin
>
>
> (defun next-buffer ()
> "Switch to the next buffer in cyclic order."
> (interactive)
> (let ((buffer (current-buffer)))
> (switch-to-buffer (other-buffer buffer t))
> (bury-buffer buffer)))
>
> (defun previous-buffer ()
> "Switch to the previous buffer in cyclic order."
> (interactive)
> (switch-to-buffer (last-buffer (current-buffer) t)))

Re: Buffers relative order

[martin rudalics]

 > Oh yes! it seems the same original behavior!

Please use this as a workaround for the moment.  I shall see later
whether it's worth to make this customizable or restore the old
behavior.

Thanks, martin

Re: Buffers relative order

[Stefan Monnier]

> Please use this as a workaround for the moment.  I shall see later
> whether it's worth to make this customizable or restore the old
> behavior.

Why would a user want to choose between the new and old behavior?


        Stefan

Re: Buffers relative order

[martin rudalics]

 >> Please use this as a workaround for the moment.  I shall see later
 >> whether it's worth to make this customizable or restore the old
 >> behavior.
 >
 > Why would a user want to choose between the new and old behavior?

The new buffer list implementation differs from the previous one in the
following sense: When I remove a buffer from a window I now show the
buffer that appeared in it before (unless it hasn't been buried in the
meantime).  That means what I did earlier when quitting a help window I
now do for windows showing non-help buffers as well.

For implementing this I use window local buffer lists which, however,
don't get saved and restored along with the desktop because desktop
doesn't save and restore window configurations yet.  So someone using
desktop currently sees different behaviors when exiting and reentering
Emacs.

martin

Re: Buffers relative order

[Stefan Monnier]

> The new buffer list implementation differs from the previous one in the
> following sense: When I remove a buffer from a window I now show the
> buffer that appeared in it before (unless it hasn't been buried in the
> meantime).  That means what I did earlier when quitting a help window I
> now do for windows showing non-help buffers as well.

That seems to be a fairly subtle distinction that's not worth
a config variable.

> For implementing this I use window local buffer lists which, however,
> don't get saved and restored along with the desktop because desktop
> doesn't save and restore window configurations yet.  So someone using
> desktop currently sees different behaviors when exiting and reentering
> Emacs.

So, IIUC the problem only appears if you use desktop.el?  So it can be
fixed by making desktop save window-local buffers.


        Stefan

Re: Buffers relative order

[martin rudalics]

 > So, IIUC the problem only appears if you use desktop.el?  So it can be
 > fixed by making desktop save window-local buffers.

If there's just one window maybe, I haven't looked into desktop yet.  If
there's more than one window things get hairy.

martin