Buffer listing in multiple frames/ttys

Buffer listing in multiple frames/ttys

[Len Trigg]

Hi all,

Many years ago I chose XEmacs, mainly becuase (at the time) it was the
only one that supported font-lock in a tty and multiple tty
connections to the one server.  A few months ago I switched over to
FSF Emacs-multi-tty and so far it's been going pretty well.  One
difference that has been niggling me is that XEmacs used to keep the
recently-used buffer listing on a per-tty/frame basis, whereas
Emacs-multi-tty seems to just have a global list.

For example, I typically have separate emacs tty's for my mail client,
for calendar/diary, and for my coding.  In XEmacs, list-buffers called
from the coding tty would list all the code-related buffers at the
top, whereas in multi-tty emacs, I get a mixture of buffers from all
three ttys.  It's obvious that the XEmacs way is preferrable.  Is
there any chance of this feature being implemented in the multi-tty
patch? (or is it even something that applies to the main Emacs branch?)

Cheers,
Len.

(The other issue is that other ttys get blocked if one of them is
waiting on input in the minibuffer.  Apparently this single keyboard
mode is intentional, but it's annoying nontheless, and certainly a
trick for new players)

Re: Buffer listing in multiple frames/ttys

[Károly Lőrentey]

[-- Attachment #1.1.1: Type: text/plain, Size: 1359 bytes --]

[emacs-devel in Cc: because I think the included patch should be
applied on the CVS trunk.]

Len Trigg <lenbok@gmail.com> writes:
> Many years ago I chose XEmacs, mainly becuase (at the time) it was the
> only one that supported font-lock in a tty and multiple tty
> connections to the one server.  A few months ago I switched over to
> FSF Emacs-multi-tty and so far it's been going pretty well.  One
> difference that has been niggling me is that XEmacs used to keep the
> recently-used buffer listing on a per-tty/frame basis, whereas
> Emacs-multi-tty seems to just have a global list.

I have good news!  Emacs has per-frame buffer-lists as well: see
<info:(elisp)The Buffer List>.

> For example, I typically have separate emacs tty's for my mail client,
> for calendar/diary, and for my coding.  In XEmacs, list-buffers called
> from the coding tty would list all the code-related buffers at the
> top, whereas in multi-tty emacs, I get a mixture of buffers from all
> three ttys.  It's obvious that the XEmacs way is preferrable.  Is
> there any chance of this feature being implemented in the multi-tty
> patch? (or is it even something that applies to the main Emacs
> branch?)

`list-buffers' (C-x C-b) does not use the frame-local buffer-list, but
rather the global one.  This seems like a bug in the CVS trunk, easily
fixed by a one-line patch:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.1.2: Type: text/x-patch, Size: 414 bytes --]

--- orig/lisp/buff-menu.el
+++ mod/lisp/buff-menu.el
@@ -717,7 +717,7 @@
 				   (if (memq c '(?\n ?\s)) c underline))
 				 header)))))
       ;; Collect info for every buffer we're interested in.
-      (dolist (buffer (or buffer-list (buffer-list)))
+      (dolist (buffer (or buffer-list (buffer-list (selected-frame))))
 	(with-current-buffer buffer
 	  (let ((name (buffer-name))
 		(file buffer-file-name))

[-- Attachment #1.1.3: Type: text/plain, Size: 577 bytes --]

 
2005-11-24  Lőrentey Károly  <lorentey@elte.hu>

	* buff-menu.el (list-buffers-noselect): Display the selected
          frame's buffer list, not the global one.

Any objections?

> (The other issue is that other ttys get blocked if one of them is
> waiting on input in the minibuffer.  Apparently this single keyboard
> mode is intentional, but it's annoying nontheless, and certainly a
> trick for new players)

I agree, but it's very hard to fix it.  I wonder what did the XEmacs
developers do; did they simply ignore the underlying problem?

-- 
Károly

[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Buffer listing in multiple frames/ttys

[Lőrentey Károly]

[-- Attachment #1.1: Type: text/plain, Size: 325 bytes --]

Lőrentey Károly <lorentey@elte.hu> writes:
> 2005-11-24  Lőrentey Károly  <lorentey@elte.hu>
>
> 	* buff-menu.el (list-buffers-noselect): Display the selected
>       frame's buffer list, not the global one.
>
> Any objections?

Applied.  (This was my first Emacs commit, look out for breakage.)

-- 
Károly

[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]

[-- Attachment #2: Type: text/plain, Size: 145 bytes --]

_______________________________________________
multi-tty mailing list
multi-tty@lists.fnord.hu
http://lists.fnord.hu/mailman/listinfo/multi-tty

RE: Buffer listing in multiple frames/ttys

[Drew Adams]

    > 	* buff-menu.el (list-buffers-noselect): Display the selected
    >       frame's buffer list, not the global one.
    >
    > Any objections?
    
    Applied.  (This was my first Emacs commit, look out for breakage.)
    
The original email on this spoke only of doing this for tty, IIUC.  I don't use Emacs as tty, so I didn't object. The change seems to affect general Emacs use, however.

I was about to object now, thinking that this would show only the buffers that had been selected in the given frame, but, trying it, I see that it still shows all buffers in non-tty Emacs (which is good, for me).

Function `buffer-list' (which supplies the buffer list to `list-buffers-noselect') lists all buffers - it just puts those for the given frame first. So, this change makes the buffer-menu order be different, depending on what frame you call it from. For people, like me, who use pop-up-frames = t, this means that the order is usually different, depending on what _buffer_ you call it from.

I can live with that reordering behavior, I guess. But, it might be best if, as before, the same order were used for the buffer menu, regardless of which frame you call it from. I'm not sure about that (hence, "might be") - what do others think?

I'm also curious how this change actually fixes the problem reported for tty - doesn't function `buffer-list' still list all buffers, so that all get listed in the buffer menu? I don't see where the code does anything different for the tty case.

Re: Buffer listing in multiple frames/ttys

[Lőrentey Károly]

Drew Adams <drew.adams@oracle.com> writes:
> Function `buffer-list' (which supplies the buffer list to
> list-buffers-noselect') lists all buffers - it just puts those for the
> given frame first. So, this change makes the buffer-menu order be
> different, depending on what frame you call it from.

Yes.  The list still contains all the buffers, but the buffers that
were recently displayed in the current frame are listed first.

> For people, like me, who use pop-up-frames = t, this means that the
> order is usually different, depending on what _buffer_ you call it
> from.

That's true.  Although the newly created frame is initialized with the
global buffer-list, `list-buffers' populates the list using the old
frame's local version.

> I can live with that reordering behavior, I guess. But, it might be
> best if, as before, the same order were used for the buffer menu,
> regardless of which frame you call it from. I'm not sure about that
> (hence, "might be") - what do others think?

Well, it might be question a personal preference.  I usually sort my
frames thematically (one for email, one for coding, etc), so a local
buffer list makes much more sense.  It also seems like the only
reasonable behaviour in a multi-display environment.  

The iswitchb package has a similar case, and it provides the
iswitchb-use-frame-buffer-list variable to let the user decide.

Is the reordering really inconvenient with pop-up-frames, or is it
just surprising at first?

> I'm also curious how this change actually fixes the problem reported
> for tty - doesn't function `buffer-list' still list all buffers, so
> that all get listed in the buffer menu? I don't see where the code
> does anything different for the tty case.

AFAICS the submitter only wanted a local ordering; he did not want to
eliminate references to buffers on other displays.

-- 
Károly

RE: Buffer listing in multiple frames/ttys

[Drew Adams]

    > For people, like me, who use pop-up-frames = t, this means that the
    > order is usually different, depending on what _buffer_ you call it
    > from.
    > I can live with that reordering behavior, I guess. But, it might be
    > best if, as before, the same order were used for the buffer menu,
    > regardless of which frame you call it from. I'm not sure about that
    > (hence, "might be") - what do others think?
    
    Well, it might be question a personal preference.  I usually sort my
    frames thematically (one for email, one for coding, etc), so a local
    buffer list makes much more sense.  It also seems like the only
    reasonable behaviour in a multi-display environment. 

Using pop-up-frames = t is quite different from having a set of fixed, thematic frames. It means that _each_ buffer is opened in a separate frame.

I don't think that this question is as much a "question of personal preference" as it is a question of the value of pop-up-frames (which is a question of personal preference, of course). I think that people who use pop-up-frames = t will be confused or annoyed by the new behavior - but I'll ask again: "What do others think?"
    
    The iswitchb package has a similar case, and it provides the
    iswitchb-use-frame-buffer-list variable to let the user decide.
    
    Is the reordering really inconvenient with pop-up-frames, or is it
    just surprising at first?

To understand what your change means for users with pop-up-frames = t, imagine that the order of the buffer menu were changed each time you called it from a different Emacs _window_ - that's what it's like. Would you be just "surprised" or also "annoyed" by such behavior? I haven't played with the new behavior much, but I think I'll be annoyed by it.

So, if it's not too much trouble, I'd suggest having the code test whether pop-up-frames is non-nil and, if so, using the old behavior. This would be less confusing and more manageable, for people using pop-up-frames = t. 

Also, if someone has gone to the trouble of sorting the buffer menu, and then calls it again, from a different frame, your change will require manually resorting it, just to get back the last sort order. I would prefer that the buffer menu not get resorted this way (order changed) behind my back.
    
    > I'm also curious how this change actually fixes the problem reported
    > for tty - doesn't function `buffer-list' still list all buffers, so
    > that all get listed in the buffer menu? I don't see where the code
    > does anything different for the tty case.
    
    AFAICS the submitter only wanted a local ordering; he did not want to
    eliminate references to buffers on other displays.

That was not my reading of the OP, but the behavior for tty makes no difference to me. Thanks for confirming that my reading of the code was correct, in any case.

Re: Buffer listing in multiple frames/ttys

[Lőrentey Károly]

Drew Adams <drew.adams@oracle.com> writes:
> Using pop-up-frames = t is quite different from having a set of
> fixed, thematic frames. It means that _each_ buffer is opened in a
> separate frame.

OK, but what is your point?  If you don't ever change buffers in a
frame, then every time it is selected, its local buffer list will be
the same as the global list.  Therefore, you shouldn't see any
difference between the old and the new code when you call
`list-buffers'.

> To understand what your change means for users with pop-up-frames =
> t, imagine that the order of the buffer menu were changed each time
> you called it from a different Emacs _window_ - that's what it's
> like.

I don't need to imagine it: it behaved that way even before the
change--`list-buffers' always lists the most recently displayed buffer
first, i.e., the one that was selected at the time of the
`list-buffers' invocation.  If you run it from a different window, you
get a different list, with that window's buffer in the topmost line.
No?  Try it with "emacs -Q".

My change simply groups the buffers that were recently displayed in
the current frame closer together.  It doesn't fundamentally change
the way `list-buffers' works.

> So, if it's not too much trouble, I'd suggest having the code test
> whether pop-up-frames is non-nil and, if so, using the old
> behavior. This would be less confusing and more manageable, for
> people using pop-up-frames = t.

It's not too much trouble at all; I am also willing to back out the
change altogether.  But are you sure you know how `list-buffers'
originally worked?

> Also, if someone has gone to the trouble of sorting the buffer menu,

How do you do that?  If you mean by `Buffer-menu-sort-column'
(clicking on the header line sets that) then the new version doesn't
affect that.

> and then calls it again, from a different frame, your change will
> require manually resorting it, just to get back the last sort
> order.

The old code already did that.  The new code simply uses a slightly
different order.

-- 
Károly

RE: Buffer listing in multiple frames/ttys

[Drew Adams]

    Drew Adams <drew.adams@oracle.com> writes:
    > Using pop-up-frames = t is quite different from having a set of
    > fixed, thematic frames. It means that _each_ buffer is opened in a
    > separate frame.
    
    OK, but what is your point?  If you don't ever change buffers in a
    frame, then every time it is selected, its local buffer list will be
    the same as the global list.  Therefore, you shouldn't see any
    difference between the old and the new code when you call
    `list-buffers'.

That's not what I see. 

emacs -q

load your version of buff-menu.el

(setq pop-up-frames t)

open several buffers (they will be in separate frames)

call buffer-menu from various buffers

I see the buffer-menu order change when I call buffer-menu from different buffers. And it is not just the first (most recent) buffer that changes.
    
    > To understand what your change means for users with pop-up-frames =
    > t, imagine that the order of the buffer menu were changed each time
    > you called it from a different Emacs _window_ - that's what it's
    > like.
    
    I don't need to imagine it: it behaved that way even before the
    change--`list-buffers' always lists the most recently displayed buffer
    first, i.e., the one that was selected at the time of the
    `list-buffers' invocation.  If you run it from a different window, you
    get a different list, with that window's buffer in the topmost line.
    No?  Try it with "emacs -Q".

The default ordering is chronological, so, yes, the most recent buffer is always first. The relative order of the other buffers is not changed, however (currently). 

Your reordering goes beyond that - the change in order is confusing, unless one is thinking in terms of multiple buffers per frame and one knows about the new behavior. That means that the new behavior would need to be documented explicitly, or else people will not understand what they see.
    
    My change simply groups the buffers that were recently displayed in
    the current frame closer together.  It doesn't fundamentally change
    the way `list-buffers' works.
    
    > So, if it's not too much trouble, I'd suggest having the code test
    > whether pop-up-frames is non-nil and, if so, using the old
    > behavior. This would be less confusing and more manageable, for
    > people using pop-up-frames = t.
    
    It's not too much trouble at all; I am also willing to back out the
    change altogether.  But are you sure you know how `list-buffers'
    originally worked?
    
    > Also, if someone has gone to the trouble of sorting the buffer menu,
    
    How do you do that?  If you mean by `Buffer-menu-sort-column'
    (clicking on the header line sets that) then the new version doesn't
    affect that.

You are right about that. I was mistaken (see below).
    
    > and then calls it again, from a different frame, your change will
    > require manually resorting it, just to get back the last sort
    > order.
    
    The old code already did that.  The new code simply uses a slightly
    different order.
    
No, I was wrong about needing to manually re-sort. You were correct, above, when you said that your code doesn't change the sorted behavior. One didn't need to re-sort before (it stays as last sorted), and one doesn't need to re-sort after your change. IOW, IIUC, your code only affects the order for a chronological sort (the default sort).

Given that, I can't say I'm annoyed by your change. I was thinking of the (imagined) need to re-sort.

[However, I have my own extension to the column-sorting that adds a Time column, which shows the `buffer-display-time'. If I sort on that column, will I need to re-sort? I don't know - is `buffer-display-time' what is used in your ordering? That's what my "Time" column uses.]

BTW, I don't see any way for a user to get back the chronological sort, after having sorted by some column. This has nothing to do with your change. Once sorted, the sort order stays until you click to impose a different sort order - and there is no way to click to get a chronological sort.

I never noticed that before. That seems like a bug (misfeature), to me. If ever it is fixed, then we _might_ need to review your change - that is, if it then starts requiring people to manually re-sort.

Thanks,

 Drew    

Re: Buffer listing in multiple frames/ttys

[Luc Teirlinck]

Drew Adams wrote:

   BTW, I don't see any way for a user to get back the chronological
   sort, after having sorted by some column.

Just invoke the *same* column button again.  These buttons _toggle_
between sorting according to the (previously global, now
frame-specific) buffer list and their own specific sort.

Sincerely,

Luc.

RE: Buffer listing in multiple frames/ttys

[Drew Adams]

       BTW, I don't see any way for a user to get back the chronological
       sort, after having sorted by some column.

    Just invoke the *same* column button again.  These buttons _toggle_
    between sorting according to the (previously global, now
    frame-specific) buffer list and their own specific sort.

OK. Thanks.

(In my own version, clicking the same column again reverses the sort order
for that column (ascending/descending). But I also have a Time column, so I
can get the chronological sort that way.)

Re: Buffer listing in multiple frames/ttys

[Lőrentey Károly]

[-- Attachment #1: Type: text/plain, Size: 1611 bytes --]

Drew Adams <drew.adams@oracle.com> writes:
> The default ordering is chronological, so, yes, the most recent
> buffer is always first. The relative order of the other buffers is
> not changed, however (currently).
>
> Your reordering goes beyond that - the change in order is confusing,
> unless one is thinking in terms of multiple buffers per frame and
> one knows about the new behavior. 

Well, if there is any change in the relative order, then that implies
that the frames sometimes change what buffer they display.  The
`buffer-list' frame parameter contains a chronological list of buffers
that were ever displayed in the frame.  The new code will not change
the relative order of buffers in *Buffer List* unless this list has
more than one entry.  But that would imply that the user does use
multiple buffers per frame, so arguably the new code can be useful.
How about that! :-)

I think we have spent too much time on this.  I agree that there is no
point in having frame-local buffer lists when pop-up-frames is set to
t, so I propose in that case we continue to use the global
buffer-list, as before.  However, the frame-local version does have
important benefits for the "thematic frame" people and when there are
multiple terminals, so let's keep it enabled when pop-up-frames is not
set.

> That means that the new behavior would need to be documented
> explicitly, or else people will not understand what they see.

I will do that, of course.

> Given that, I can't say I'm annoyed by your change. I was thinking
> of the (imagined) need to re-sort.

So, should I apply this patch or not? :-)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 1027 bytes --]

Index: buff-menu.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/buff-menu.el,v
retrieving revision 1.95
diff -u -3 -p -r1.95 buff-menu.el
*** buff-menu.el	28 Nov 2005 14:36:06 -0000	1.95
--- buff-menu.el	29 Nov 2005 09:48:51 -0000
***************
*** 722,728 ****
  				   (if (memq c '(?\n ?\s)) c underline))
  				 header)))))
        ;; Collect info for every buffer we're interested in.
!       (dolist (buffer (or buffer-list (buffer-list (selected-frame))))
  	(with-current-buffer buffer
  	  (let ((name (buffer-name))
  		(file buffer-file-name))
--- 722,731 ----
  				   (if (memq c '(?\n ?\s)) c underline))
  				 header)))))
        ;; Collect info for every buffer we're interested in.
!       (dolist (buffer (or buffer-list
! 			  ;; Use the frame-local list when it makes sense.
! 			  (buffer-list (and (not pop-up-frames)
! 					    (selected-frame)))))
  	(with-current-buffer buffer
  	  (let ((name (buffer-name))
  		(file buffer-file-name))

[-- Attachment #3: Type: text/plain, Size: 601 bytes --]


> [However, I have my own extension to the column-sorting that adds a
> Time column, which shows the `buffer-display-time'. If I sort on
> that column, will I need to re-sort? I don't know - is
> `buffer-display-time' what is used in your ordering? That's what my
> "Time" column uses.]

No, Emacs simply uses the above mentioned frame parameter together
with the global list to generate the frame-local ordering---it doesn't
mess with the recorded display time for this.

Therefore, I think that using the frame-local buffer-list should not
affect your sorting results.

-- 
Károly

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

RE: Buffer listing in multiple frames/ttys

[Drew Adams]

    > The default ordering is chronological, so, yes, the most recent
    > buffer is always first. The relative order of the other buffers is
    > not changed, however (currently).
    >
    > Your reordering goes beyond that - the change in order is confusing,
    > unless one is thinking in terms of multiple buffers per frame and
    > one knows about the new behavior.
   
    Well, if there is any change in the relative order, then that implies
    that the frames sometimes change what buffer they display.  The
    `buffer-list' frame parameter contains a chronological list of buffers
    that were ever displayed in the frame.  The new code will not change
    the relative order of buffers in *Buffer List* unless this list has
    more than one entry.  But that would imply that the user does use
    multiple buffers per frame, so arguably the new code can be useful.
    How about that! :-)

That's not what I see. I gave explicit instructions - here they are again. One buffer per frame, yet your code changes the order, and not just for the first buffer listed. Did you try this?  (I'm using a July snapshot of CVS, but I doubt that makes a difference here)

 emacs -q

 load your version of buff-menu.el

 (setq pop-up-frames t)

 open several buffers (they will be in separate frames)

 C-x C-b from various buffers

Perhaps there is a bug in the buffer list for each frame - or perhaps the doc (Info) is not clear? When I do (frame-parameter (selected-frame) 'buffer-list) in the different frames, each is a list of multiple buffers (in spite of pop-up-frames forcing one buffer per frame), and they are in different orders.

Just what is the meaning of frame parameter `buffer-list' - in particular, when there is only (ever) one buffer per frame? Here is the complete Info explanation of `buffer-list':

     A list of buffers that have been selected in this frame, ordered
     most-recently-selected first.

I'm not sure what is meant by a buffer being "selected" in a frame (displayed?), but when pop-up-frames = t, there is only one buffer that is displayed in a given frame, by default. If you just open new buffers (e.g. `C-x 4 f', `C-x d', *Help*, *info*, whatever), by default they each open in a new frame. Why would a new frame's `buffer-list' parameter list multiple buffers? What is the significance of the other buffers in that list? I would expect that to be explained in Info (if that is not a bug).

That behavior (bug or intended?) may be behind the reordering of multiple buffers (that is, not just moving the current buffer to the top) that is new with your change. 

IOW, you were saying that only the current buffer's position is changed in the order, but that's not what I see (instructions above). That is likely not your fault but a by-product of listing multiple buffers for a one-buffer frame.
   
    I think we have spent too much time on this.  I agree that there is no
    point in having frame-local buffer lists when pop-up-frames is set to
    t, so I propose in that case we continue to use the global
    buffer-list, as before.  However, the frame-local version does have
    important benefits for the "thematic frame" people and when there are
    multiple terminals, so let's keep it enabled when pop-up-frames is not
    set.

That sounds good to me. If people have other opinions, please speak up.
   
    > That means that the new behavior would need to be documented
    > explicitly, or else people will not understand what they see.
   
    I will do that, of course.

Thanks.
   
    > Given that, I can't say I'm annoyed by your change. I was thinking
    > of the (imagined) need to re-sort.
   
    So, should I apply this patch or not? :-)

I'm OK with it, given that the same list will appear, in the same order, if pop-up-frames = t.

I'd still like to know about the `buffer-list' frame parameter. At the least, I'd say that what I see doesn't jibe with what Info says, or else I'm reading that wrong.

Thanks,

  Drew
   
    

Re: Buffer listing in multiple frames/ttys

[Luc Teirlinck]

Drew Adams wrote:

   I'm not sure what is meant by a buffer being "selected" in a frame
   (displayed?), but when pop-up-frames = t, there is only one buffer
   that is displayed in a given frame, by default. If you just open
   new buffers (e.g. `C-x 4 f', `C-x d', *Help*, *info*, whatever), by
   default they each open in a new frame.

Even with pop-up-frames set to t, `C-x d' and `C-h i' display dired
and *info* in the selected frame (actually, in the selected window).

You have other customizations.  Just experiment with `emacs -q' and
`pop-up-frames' set to t.

Sincerely,

Luc.

RE: Buffer listing in multiple frames/ttys

[Drew Adams]

       I'm not sure what is meant by a buffer being "selected" in a frame
       (displayed?), but when pop-up-frames = t, there is only one buffer
       that is displayed in a given frame, by default. If you just open
       new buffers (e.g. `C-x 4 f', `C-x d', *Help*, *info*, whatever), by
       default they each open in a new frame.

    Even with pop-up-frames set to t, `C-x d' and `C-h i' display dired
    and *info* in the selected frame (actually, in the selected window).

I meant C-x 4 d. You're right about `C-h i', of course.

What I meant was: open buffers in new frames (in whatever way). I wouldn't
expect those new frames to have multiple-buffer values for frame-parameter
`buffer-list', but they do.

    You have other customizations.  Just experiment with `emacs -q' and
    `pop-up-frames' set to t.

I did. And I just did so again.

 emacs -q

 M-x set-variable pop-up-frames RET t RET
 C-x 4 f <some file>
 C-x 4 d <some directory>
 C-h f <some function>

Do C-x C-b in each buffer. I get these values for the `buffer-list'
parameter:

 - for the file buffer: 1) the file buffer, 2) the minibuffer,
   3) the directory buffer

 - for the directory buffer: 1) the directory buffer, 2) the minibuffer

 - for the *Help* buffer: 1) the *Help* buffer, 2) the minibuffer,
   3) the directory buffer

That's with just 3 buffers (+ the minibuffer). It appears that when I do,
for instance, C-x 4 d (or f), the new buffer is also added to the
`buffer-list' of the frame that I executed the command from. IOW, I suspect
that the code is assuming that the new buffer will be "selected" (displayed)
in the same frame, so it gets added to the list.

Also, if I click a buffer name (e.g. *Help*) in buffer *Buffer List*, then
*Buffer List* gets added to the `buffer-list' of the other frame (e.g.
*Help*), even if it already existed.

Again, this is a CVS snapshot from July. If others don't see such behavior,
then perhaps this has been fixed.

Re: Buffer listing in multiple frames/ttys

[Lőrentey Károly]

Drew Adams <drew.adams@oracle.com> writes:
>  C-x C-b from various buffers
>
> Perhaps there is a bug in the buffer list for each frame - or
> perhaps the doc (Info) is not clear? When I do (frame-parameter
> (selected-frame) 'buffer-list) in the different frames, each is a
> list of multiple buffers (in spite of pop-up-frames forcing one
> buffer per frame), and they are in different orders.

I think I have found the problem.  When you use C-x 4 C-f, the new
buffer gets displayed by `pop-to-buffer', and that function records
the newly created buffer in the buffer list of the existing frame as
well as the new frame.  This is clearly not right.

I removed the duplicate call to record_buffer in CVS.

-- 
Károly

Re: Buffer listing in multiple frames/ttys

[Luc Teirlinck]

Lorentey Karoly wrote:

   I agree that there is no point in having frame-local buffer lists
   when pop-up-frames is set to t, so I propose in that case we
   continue to use the global buffer-list, as before.

`pop-up-frames' is mainly a way of preventing help buffers and such
from messing up window configurations.  `C-x b' still gives buffers in
the selected frame.  `M-x buffer-menu' still gives the Buffer Menu in
the selected frame.  Granted `C-x C-b' pops up the Buffer Menu in a
separate frame (and selects it, which seems strange).  But if you
auto-revert the Buffer Menu, then after at most auto-revert-interval
(default 5) seconds, a displayed Buffer Menu frame will automatically
update for the currently selected frame.

The frame local buffer list only makes no sense if you not only set
pop-up-frames to t, but, much more importantly, always use C-x 5 b
instead of C-x b, as Drew apparently does.  (I believe that he must
have rebound C-x b to run `C-x 5 b')  But that is highly personal usage.

On the other hand, if you do not use separate frames systematically
for separate themes, then usually the least important buffers are the
_globally_ least recent ones.  So in that case you might prefer the
old behavior, regardless of the value of `pop-up-frames'.

   So, should I apply this patch or not? :-)

For the reasons explained above, I would prefer a user option, with
the new behavior as default.  In other words, I would prefer the
following patch, which I could install if we decide to do that:

===File ~/buff-menu-diff====================================
*** buff-menu.el	28 Nov 2005 14:10:16 -0600	1.95
--- buff-menu.el	29 Nov 2005 11:27:05 -0600	
***************
*** 89,94 ****
--- 89,102 ----
    :type 'number
    :group 'Buffer-menu)
  
+ (defcustom Buffer-menu-use-frame-buffer-list t
+   "If non-nil, the Buffer Menu uses the selected frame's buffer list.
+ If nil, it uses the global buffer list.  This variable matters if
+ the Buffer Menu is sorted by visited order, as it is by default."
+   :type 'boolean
+   :group 'Buffer-menu
+   :version "22.1")
+ 
  ;; This should get updated & resorted when you click on a column heading
  (defvar Buffer-menu-sort-column nil
    "*2 for sorting by buffer names.  5 for sorting by file names.
***************
*** 722,728 ****
  				   (if (memq c '(?\n ?\s)) c underline))
  				 header)))))
        ;; Collect info for every buffer we're interested in.
!       (dolist (buffer (or buffer-list (buffer-list (selected-frame))))
  	(with-current-buffer buffer
  	  (let ((name (buffer-name))
  		(file buffer-file-name))
--- 730,739 ----
  				   (if (memq c '(?\n ?\s)) c underline))
  				 header)))))
        ;; Collect info for every buffer we're interested in.
!       (dolist (buffer (or buffer-list
! 			  (buffer-list
! 			   (when Buffer-menu-use-frame-buffer-list
! 			     (selected-frame)))))
  	(with-current-buffer buffer
  	  (let ((name (buffer-name))
  		(file buffer-file-name))
============================================================

Re: Buffer listing in multiple frames/ttys

[Luc Teirlinck]

Sorry if this arrives twice, but I believe that the CC to emacs-devel
somehow got lost the first time I sent this.

Lorentey Karoly wrote:

   I agree that there is no point in having frame-local buffer lists
   when pop-up-frames is set to t, so I propose in that case we
   continue to use the global buffer-list, as before.

`pop-up-frames' is mainly a way of preventing help buffers and such
from messing up window configurations.  `C-x b' still gives buffers in
the selected frame.  `M-x buffer-menu' still gives the Buffer Menu in
the selected frame.  Granted `C-x C-b' pops up the Buffer Menu in a
separate frame (and selects it, which seems strange).  But if you
auto-revert the Buffer Menu, then after at most auto-revert-interval
(default 5) seconds, a displayed Buffer Menu frame will automatically
update for the currently selected frame.

The frame local buffer list only makes no sense if you not only set
pop-up-frames to t, but, much more importantly, always use C-x 5 b
instead of C-x b, as Drew apparently does.  (I believe that he must
have rebound C-x b to run `C-x 5 b')  But that is highly personal usage.

On the other hand, if you do not use separate frames systematically
for separate themes, then usually the least important buffers are the
_globally_ least recent ones.  So in that case you might prefer the
old behavior, regardless of the value of `pop-up-frames'.

   So, should I apply this patch or not? :-)

For the reasons explained above, I would prefer a user option, with
the new behavior as default.  In other words, I would prefer the
following patch, which I could install if we decide to do that:

===File ~/buff-menu-diff====================================
*** buff-menu.el	28 Nov 2005 14:10:16 -0600	1.95
--- buff-menu.el	29 Nov 2005 11:27:05 -0600	
***************
*** 89,94 ****
--- 89,102 ----
    :type 'number
    :group 'Buffer-menu)
  
+ (defcustom Buffer-menu-use-frame-buffer-list t
+   "If non-nil, the Buffer Menu uses the selected frame's buffer list.
+ If nil, it uses the global buffer list.  This variable matters if
+ the Buffer Menu is sorted by visited order, as it is by default."
+   :type 'boolean
+   :group 'Buffer-menu
+   :version "22.1")
+ 
  ;; This should get updated & resorted when you click on a column heading
  (defvar Buffer-menu-sort-column nil
    "*2 for sorting by buffer names.  5 for sorting by file names.
***************
*** 722,728 ****
  				   (if (memq c '(?\n ?\s)) c underline))
  				 header)))))
        ;; Collect info for every buffer we're interested in.
!       (dolist (buffer (or buffer-list (buffer-list (selected-frame))))
  	(with-current-buffer buffer
  	  (let ((name (buffer-name))
  		(file buffer-file-name))
--- 730,739 ----
  				   (if (memq c '(?\n ?\s)) c underline))
  				 header)))))
        ;; Collect info for every buffer we're interested in.
!       (dolist (buffer (or buffer-list
! 			  (buffer-list
! 			   (when Buffer-menu-use-frame-buffer-list
! 			     (selected-frame)))))
  	(with-current-buffer buffer
  	  (let ((name (buffer-name))
  		(file buffer-file-name))
============================================================

Re: Buffer listing in multiple frames/ttys

[Chong Yidong]

Never mind; I found out that it's not necessary to use hard-newline in
those places.  I've reverted the 2005-11-29 changes to mailheader.el

Re: Buffer listing in multiple frames/ttys

[Chong Yidong]

> Never mind; I found out that it's not necessary to use 
  hard-newline in
> those places.  I've reverted the 2005-11-29 changes to 
  mailheader.el

Wrong thread, sorry.

RE: Buffer listing in multiple frames/ttys

[Drew Adams]

      Lorentey Karoly wrote:
       I agree that there is no point in having frame-local buffer lists
       when pop-up-frames is set to t, so I propose in that case we
       continue to use the global buffer-list, as before.

    `pop-up-frames' is mainly a way of preventing help buffers and such
    from messing up window configurations.

I don't really agree, but I'm not sure my disagreement is important here. My
guess (why? I don't know) is that most people who set `pop-up-frames' = t
are trying to get a one-buffer-per-frame behavior for Emacs. That is not as
easy as simply setting that variable, however, so such behavior cannot be
said to be the purpose of that variable, admittedly.

    `C-x b' still gives buffers in
    the selected frame.  `M-x buffer-menu' still gives the Buffer Menu in
    the selected frame.  ...

    The frame local buffer list only makes no sense if you not only set
    pop-up-frames to t, but, much more importantly, always use C-x 5 b
    instead of C-x b, as Drew apparently does.  (I believe that he must
    have rebound C-x b to run `C-x 5 b')  But that is highly personal usage.

I use C-x 4 b (4 works like 5, if pop-up-frames is t) when I don't want to
replace the current buffer - just as you might use it to open a buffer in
another window: no difference. I doubt that I work much differently from
others - I just use frames in place of windows.

The point is not that I don't reuse a frame for a different buffer - it is
that I have only one buffer per frame (most of the time) - that is, I use
frames like most people use Emacs windows. If you keep that analogy in mind,
you'll understand why this change makes little sense for my use case.

Whenever I don't bother to create a new frame (e.g. I use `C-x d' instead of
`C-x 4 d'), I don't _care_ about what was in the frame before (I use `C-x
C-v' too). In that case (as in all other cases), I don't care about the
frame-local buffer list - I don't want to see it or have its order taken
into account anywhere.

In short, I use frames pretty much like most people use Emacs windows. You
wouldn't find a window-local buffer list useful, would you? You wouldn't
want the Buffer Menu to be ordered in any way based on that, would you?
That's the point.

(BTW - In order to make frames behave well, I also make special buffers
(*...*) use dedicated windows, and redefine `switch-to-buffer' to use a
different window if the current window is dedicated, and jump through a few
other hoops.)

    On the other hand, if you do not use separate frames systematically
    for separate themes, then usually the least important buffers are the
    _globally_ least recent ones.  So in that case you might prefer the
    old behavior, regardless of the value of `pop-up-frames'.

       So, should I apply this patch or not? :-)

    For the reasons explained above, I would prefer a user option, with
    the new behavior as default.  In other words, I would prefer the
    following patch, which I could install if we decide to do that:

    + (defcustom Buffer-menu-use-frame-buffer-list t
    +   "If non-nil, the Buffer Menu uses the selected frame's buffer list.
    + If nil, it uses the global buffer list.  This variable matters if
    + the Buffer Menu is sorted by visited order, as it is by default."

Yes, I, at least, would prefer having the option. Thanks.

I still believe that most people who use pop-up-frames = t will want to set
this option to nil (so, they would prefer that that behavior be the default
for non-nil pop-up-frames), but I don't mind setting the option to get the
old behavior.

Re: Buffer listing in multiple frames/ttys

[Juri Linkov]

The current implementation of `buffer-list' frame parameter doesn't
preserve the correct ordering of buffers selected in the same frame.

After using `next-window' in one frame, `previous-window' in another
frame gets the buffer buried in the first frame, but not in the
same frame where it is called.

Since two commands `next-window' and `previous-window' make a ring
from the buffer list, this ring becomes broken when used in two or
more frames.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Buffer listing in multiple frames/ttys

[Richard M. Stallman]

    Since two commands `next-window' and `previous-window' make a ring
    from the buffer list,

Could you say that in different words?  I can't figure out what
it means.

Re: Buffer listing in multiple frames/ttys

[Lőrentey Károly]

[-- Attachment #1.1.1.1: Type: text/plain, Size: 590 bytes --]

Juri Linkov <juri@jurta.org> writes:
> The current implementation of `buffer-list' frame parameter doesn't
> preserve the correct ordering of buffers selected in the same frame.
>
> After using `next-window' in one frame, `previous-window' in another
> frame gets the buffer buried in the first frame, but not in the
> same frame where it is called.
>
> Since two commands `next-window' and `previous-window' make a ring
> from the buffer list, this ring becomes broken when used in two or
> more frames.

I think you mean `next-buffer' and `prev-buffer' here, no?
Does this patch fix it?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.1.1.2: Type: text/x-patch, Size: 710 bytes --]

*** lisp/simple.el~	2005-11-30 19:55:19.000000000 +0100
--- lisp/simple.el	2005-12-03 16:29:55.000000000 +0100
***************
*** 62,68 ****
  (defun prev-buffer ()
    "Switch to the previous buffer in cyclic order."
    (interactive)
!   (let ((list (nreverse (buffer-list)))
  	found)
      (while (and (not found) list)
        (let ((buffer (car list)))
--- 62,70 ----
  (defun prev-buffer ()
    "Switch to the previous buffer in cyclic order."
    (interactive)
!   (let ((list (nconc ;; Consider the locally used buffers first.
! 	       (reverse (frame-parameter nil 'buffer-list))
! 	       (nreverse (buffer-list))))
  	found)
      (while (and (not found) list)
        (let ((buffer (car list)))

[-- Attachment #1.1.1.3: Type: text/plain, Size: 15 bytes --]


-- 
Károly

[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Buffer listing in multiple frames/ttys

[Juri Linkov]

>> The current implementation of `buffer-list' frame parameter doesn't
>> preserve the correct ordering of buffers selected in the same frame.
>>
>> After using `next-window' in one frame, `previous-window' in another
>> frame gets the buffer buried in the first frame, but not in the
>> same frame where it is called.
>>
>> Since two commands `next-window' and `previous-window' make a ring
>> from the buffer list, this ring becomes broken when used in two or
>> more frames.
>
> I think you mean `next-buffer' and `prev-buffer' here, no?

This is exactly what I meant.  Sorry for being so distrait.

> Does this patch fix it?

Not at all.  The problem is that `bury-buffer' (called from `next-buffer')
removes the buffer from the frame's buffer-list.  So a buried buffer is
no longer available from (frame-parameter nil 'buffer-list) for
`prev-buffer' called in the same frame after changing the order of
buried buffers in another frame.

Perhaps, there should be a separate list of buried buffers maintained
in a new frame parameter.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Buffer listing in multiple frames/ttys

[Richard M. Stallman]

      So a buried buffer is
    no longer available from (frame-parameter nil 'buffer-list) for
    `prev-buffer' called in the same frame after changing the order of
    buried buffers in another frame.

Why is that a problem?

Re: Buffer listing in multiple frames/ttys

[Juri Linkov]

>       So a buried buffer is
>     no longer available from (frame-parameter nil 'buffer-list) for
>     `prev-buffer' called in the same frame after changing the order of
>     buried buffers in another frame.
>
> Why is that a problem?

I often use `next-buffer' to switch to the next buffer in the buffer list,
and I expect that `prev-buffer' restores exactly the same buffers as left
with `next-buffer'.  However, after switching to another frame, and using
`next-buffer' in another frame and switching back to the original frame,
`prev-buffer' no more restores the same buffer as left with `next-buffer'
in the same frame.

(Actually I use only one Emacs frame and I switch window configurations
inside one frame.  Before switching a window configuration I set
the frame parameter `buffer-list' to the value saved in a special list.
Maybe `current-window-configuration' should store the frame's buffer list
in the window configuration, and `set-window-configuration' should restore
it automatically.  But anyway this is irrelevant to the problem that the
frame's buffer list doesn't maintain a list of frame-local buffers buried
with `prev-buffer'.  The same problem exists on multiple frames too).

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Buffer listing in multiple frames/ttys

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Date: Sun, 04 Dec 2005 23:56:34 +0200
> Cc: lorentey@elte.hu, emacs-devel@gnu.org
> 
> >       So a buried buffer is
> >     no longer available from (frame-parameter nil 'buffer-list) for
> >     `prev-buffer' called in the same frame after changing the order of
> >     buried buffers in another frame.
> >
> > Why is that a problem?
> 
> I often use `next-buffer' to switch to the next buffer in the buffer list,
> and I expect that `prev-buffer' restores exactly the same buffers as left
> with `next-buffer'.  However, after switching to another frame, and using
> `next-buffer' in another frame and switching back to the original frame,
> `prev-buffer' no more restores the same buffer as left with `next-buffer'
> in the same frame.

But originally, you said that this happens after burying the buffer.
If you want the history to work right for a buffer, why do you bury
it?  Burying a buffer tells Emacs you are no longer interested in that
buffer, I'm sure you know this.

Re: Buffer listing in multiple frames/ttys

[Juri Linkov]

> But originally, you said that this happens after burying the buffer.
> If you want the history to work right for a buffer, why do you bury
> it?  Burying a buffer tells Emacs you are no longer interested in that
> buffer, I'm sure you know this.

Burying a buffer doesn't necessarily mean I am not interested in
that buffer.  I use `next-buffer' and `prev-buffer' to cycle through
the buffer list which actually is a ring for these two commands.
The command `next-buffer' uses the function `bury-buffer' to move the
current buffer to the end of the buffer list.  I expect that `prev-buffer'
will always restore the buffer from the end of the buffer list in the
same frame.  The frame parameter `buffer-list' keeps only a list of
few visited buffers placed on the top of the whole buffer list, and thus
`prev-buffer' can't use it.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Buffer listing in multiple frames/ttys

[Richard M. Stallman]

    I often use `next-buffer' to switch to the next buffer in the buffer list,
    and I expect that `prev-buffer' restores exactly the same buffers as left
    with `next-buffer'.

Yes, it ought to.

If it fails to do so, that's a bug, so if you have a fix,
please install it.

Re: Buffer listing in multiple frames/ttys

[Károly Lőrentey]

[-- Attachment #1.1: Type: text/plain, Size: 2031 bytes --]

Juri Linkov <juri@jurta.org> writes:
> Not at all.  The problem is that `bury-buffer' (called from
> `next-buffer') removes the buffer from the frame's buffer-list.  So
> a buried buffer is no longer available from (frame-parameter nil
> 'buffer-list) for `prev-buffer' called in the same frame after
> changing the order of buried buffers in another frame.

Right.  I would say changing `bury-buffer' would be an overshoot,
though.  Perhaps `next-buffer' shouldn't call it?

The following definitions change `prev-buffer' and `next-buffer' to
follow the frame-local buffer ordering instead of the global
`buffer-list'.

	(defun next-buffer ()
	  "Switch to the next buffer in cyclic order."
	  (interactive)
	  (let ((buffer (current-buffer)))
	    (switch-to-buffer (other-buffer buffer))
	    (set-frame-parameter nil 'buffer-list
				 (nconc (delq buffer (frame-parameter nil 'buffer-list))
					(list buffer)))))
	
	(defun prev-buffer ()
	  "Switch to the previous buffer in cyclic order."
	  (interactive)
	  (let ((list (nconc ;; Consider the locally used buffers first.
		       (reverse (frame-parameter nil 'buffer-list))
		       (nreverse (buffer-list))))
		found)
	    (while (and (not found) list)
	      (let ((buffer (car list)))
		(if (and (not (get-buffer-window buffer))
			 (not (string-match "\\` " (buffer-name buffer))))
		    (setq found buffer)))
	      (setq list (cdr list)))
	    (switch-to-buffer found)))

Now, I like these definitions as it makes more sense for me to keep
the buffer cycle frame-local, but they do have one disadvantage: the
`next-buffer'/`prev-buffer' cycle will not usually contain all
buffers---just those that were displayed in the current frame.  To
reach the rest, the user needs to use `switch-to-buffer', or
equivalent.

AFAICS there have not yet been any Emacs releases with
`next-buffer'/`prev-buffer', so if the frame-local behaviour is
preferable (I think it is), then it should be safe to change them now.

-- 
Károly

[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Buffer listing in multiple frames/ttys

[Juri Linkov]

> Now, I like these definitions as it makes more sense for me to keep
> the buffer cycle frame-local, but they do have one disadvantage: the
> `next-buffer'/`prev-buffer' cycle will not usually contain all
> buffers---just those that were displayed in the current frame.  To
> reach the rest, the user needs to use `switch-to-buffer', or
> equivalent.

This is a grave disadvantage.  `next-buffer' and `prev-buffer' should be
able to cycle all buffers.

> AFAICS there have not yet been any Emacs releases with
> `next-buffer'/`prev-buffer', so if the frame-local behaviour is
> preferable (I think it is), then it should be safe to change them now.

BTW, not having `prev-buffer' in a Emacs release also gives an
opportunity to rename `prev-buffer' to `previous-buffer' to be
consistent with all other similar functions where currently we have:

prev-buffer			   previous-button
previous-char-property-change	   previous-complete-history-element
previous-completion		   previous-error
previous-error-no-select	   previous-frame
previous-history-element	   previous-line
previous-matching-history-element  previous-multiframe-window
previous-overlay-change		   previous-property-change
previous-single-property-change	   previous-window

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Buffer listing in multiple frames/ttys

[Richard M. Stallman]

    BTW, not having `prev-buffer' in a Emacs release also gives an
    opportunity to rename `prev-buffer' to `previous-buffer' to be
    consistent with all other similar functions where currently we have:

I agree.

Re: Buffer listing in multiple frames/ttys

[Richard M. Stallman]

    Right.  I would say changing `bury-buffer' would be an overshoot,
    though.  Perhaps `next-buffer' shouldn't call it?

bury-buffer is the only way to put a buffer at the end of the buffer
list.  next-buffer must call bury-buffer in order to do that.

    Now, I like these definitions as it makes more sense for me to keep
    the buffer cycle frame-local, but they do have one disadvantage: the
    `next-buffer'/`prev-buffer' cycle will not usually contain all
    buffers---just those that were displayed in the current frame.

As far as I can see, buffers that have never been displayed in this
frame WILL be included.  other-buffer will find them, and prev-buffer
will find them via the call to buffer-list.

However, I see that these functions do not find buffers that are
currently displayed in some window.  I think that these commands
should disregard whether the buffer is visible elsewhere.  That means
passing t for the 2nd arg to other-buffer, and removing some code in
prev-buffer.

Re: Buffer listing in multiple frames/ttys

[Károly Lőrentey]

[-- Attachment #1.1: Type: text/plain, Size: 3178 bytes --]

Richard Stallman <rms@gnu.org> writes:
> bury-buffer is the only way to put a buffer at the end of the buffer
> list.  next-buffer must call bury-buffer in order to do that.

OK.

I note that `bury-buffer' removes the buffer from the frame-local
buffer lists of all frames, not just the selected one.  This is an
unwanted side-effect in this case, as we want the effects of
`next-buffer' to remain frame-local.  I propose to add an optional
parameter to `bury-buffer' to support this.

>     Now, I like these definitions as it makes more sense for me to keep
>     the buffer cycle frame-local, but they do have one disadvantage: the
>     `next-buffer'/`prev-buffer' cycle will not usually contain all
>     buffers---just those that were displayed in the current frame.
>
> As far as I can see, buffers that have never been displayed in this
> frame WILL be included.  other-buffer will find them, and prev-buffer
> will find them via the call to buffer-list.

In my quoted message, the definition of next buffer appends the old
buffer to the end of the frame-local buffer list.  Therefore, the
frame-local list will be recycled continously, and subsequent
`next-buffer' calls are prevented from reaching any buffers in the
global buffer list.

I appended to the end of this message enhanced versions of
`next-buffer' and `prev-buffer' that eliminate this problem by
maintaining a new auxiliary frame-local buffer list, called
`previous-buffer-list'.  `next-buffer' prepends the old buffer to this
list, and `prev-buffer' searches this list first; otherwise the two
functions behave as in CVS.

> However, I see that these functions do not find buffers that are
> currently displayed in some window.  I think that these commands
> should disregard whether the buffer is visible elsewhere.  That means
> passing t for the 2nd arg to other-buffer, and removing some code in
> prev-buffer.

I applied that change to these new versions.  I also agree with Juri's
suggestion to rename `prev-buffer' to `previous-buffer', for
consistency with the rest of Emacs.

(defun next-buffer ()
  "Switch to the next buffer in cyclic order."
  (interactive)
  (let ((buffer (current-buffer))
	(pbl (frame-parameter nil 'previous-buffer-list)))
    (switch-to-buffer (other-buffer buffer t))
    (bury-buffer buffer)
    (set-frame-parameter nil 'previous-buffer-list
			 (cons buffer (delq buffer pbl)))))

(defun prev-buffer ()
  "Switch to the previous buffer in cyclic order."
  (interactive)
  (let ((search-list
	 #'(lambda (list)
	     "Search LIST for a valid buffer to display."
	     (let (found buffer)
	       (while (and (not found) (list))
		 (setq buffer (car list))
		 (if (and (buffer-live-p buffer)
			  (not (string-match "\\` " (buffer-name buffer))))
		     (setq found buffer)
		   (setq list (cdr list))))
	       list))))
    (let ((prev (funcall search-list (frame-parameter nil 'previous-buffer-list))))
      (set-frame-parameter nil 'previous-buffer-list (cdr prev))
      (switch-to-buffer
       (or (car prev)
	   (car (funcall search-list (nreverse (buffer-list)))))))))

-- 
Károly

[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Buffer listing in multiple frames/ttys

[Juri Linkov]

> I note that `bury-buffer' removes the buffer from the frame-local
> buffer lists of all frames, not just the selected one.  This is an
> unwanted side-effect in this case, as we want the effects of
> `next-buffer' to remain frame-local.  I propose to add an optional
> parameter to `bury-buffer' to support this.

I think this change should be made for all invocations of `bury-buffer',
not only from `next-buffer'.  Also I think recoding a buffer to the
new frame parameter should be made in `bury-buffer' instead of
`next-buffer'.  And so there is no need for a new optional parameter.
Some commands call `bury-buffer' directly, and it would be good to
record their buffers in the frame-local parameter.

> I appended to the end of this message enhanced versions of
> `next-buffer' and `prev-buffer' that eliminate this problem by
> maintaining a new auxiliary frame-local buffer list, called
> `previous-buffer-list'.  `next-buffer' prepends the old buffer to this
> list, and `prev-buffer' searches this list first; otherwise the two
> functions behave as in CVS.

These functions are much better than previous versions, but still
don't work correctly without changes in `bury-buffer'.

Instead of introducing a new frame parameter `previous-buffer-list'
what do you think about reusing the existing frame parameter `buffer-list'?
It could have a special marker delimiting a list of frame's "next" visited
buffers and "previous" visited buffers.  A nil value could serve as
such special marker.  So for example, (frame-parameter nil 'buffer-list)
could contain:

(#<buffer *b+1*> #<buffer *b+2*> nil #<buffer *b-2*> #<buffer *b-1*>)

where buffers until `nil' are buffers added by `switch-to-buffer'
(i.e. the same buffers that are currently recorded in this parameter),
and buffers after `nil' are buffers added by `bury-buffer'.
Then some functions should be changed to understand this new format of
the frame parameter `buffer-list'.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Buffer listing in multiple frames/ttys

[Károly Lőrentey]

[-- Attachment #1.1.1: Type: text/plain, Size: 2352 bytes --]

Juri Linkov <juri@jurta.org> writes:
>> I note that `bury-buffer' removes the buffer from the frame-local
>> buffer lists of all frames, not just the selected one.  This is an
>> unwanted side-effect in this case, as we want the effects of
>> `next-buffer' to remain frame-local.  I propose to add an optional
>> parameter to `bury-buffer' to support this.
>
> I think this change should be made for all invocations of
> `bury-buffer', not only from `next-buffer'. [...] And so there is no
> need for a new optional parameter.

That's fine by me.

> Also I think recoding a buffer to the new frame parameter should be
> made in `bury-buffer' instead of `next-buffer'.    Some commands call `bury-buffer'
> directly, and it would be good to record their buffers in the
> frame-local parameter.

Ah, good idea.  I implemented this in the patch at the end of this
message.  It involves adding a new element to the frame struct, and
changing switch-to-buffer, bury-buffer and kill-buffer etc. to
maintain the list.

> Instead of introducing a new frame parameter `previous-buffer-list'
> what do you think about reusing the existing frame parameter `buffer-list'?
> It could have a special marker delimiting a list of frame's "next" visited
> buffers and "previous" visited buffers.  A nil value could serve as
> such special marker.  So for example, (frame-parameter nil 'buffer-list)
> could contain:
>
> (#<buffer *b+1*> #<buffer *b+2*> nil #<buffer *b-2*> #<buffer *b-1*>)

I thought of this as well, but it would be an incompatible change that
is not strictly necessary.  The 'buffer-list frame parameter has been
in Emacs since (I think) 1997; some external packages may rely on its
current contents.  Also, using a special marker seems a bit less clean
to me than using a separate parameter.  (It is also less efficient.)

The below patch also renames `prev-buffer' to `previous-buffer', and
extends it to support the buffer-predicate frame parameter.  It
incorporates all fixes that have been suggested in this thread, except
for the customization option for disabling frame-local behaviour.
(`other-buffer' has been unconditionally using the frame-local buffer
list for years; I don't see a point in making it configurable for
next-buffer/previous-buffer either.)

If there are no objections, I will document the changes and install
them in CVS.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.1.2: Type: text/x-patch, Size: 14767 bytes --]

Index: lisp/bindings.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/bindings.el,v
retrieving revision 1.154
diff -u -3 -p -r1.154 bindings.el
*** lisp/bindings.el	28 Oct 2005 16:19:16 -0000	1.154
--- lisp/bindings.el	7 Dec 2005 14:46:48 -0000
***************
*** 338,364 ****
  (defvar mode-line-buffer-identification-keymap nil "\
  Keymap for what is displayed by `mode-line-buffer-identification'.")
  
! (defun last-buffer () "\
! Return the last non-hidden buffer in the buffer list."
!   ;; This logic is more or less copied from bury-buffer,
!   ;; except that we reverse the buffer list.
!   (let ((list (nreverse (buffer-list (selected-frame))))
! 	(pred (frame-parameter nil 'buffer-predicate))
! 	found notsogood)
!     (while (and list (not found))
!       (unless (or (eq (aref (buffer-name (car list)) 0) ? )
! 		  ;; If the selected frame has a buffer_predicate,
! 		  ;; disregard buffers that don't fit the predicate.
! 		  (and pred (not (funcall pred (car list)))))
! 	(if (get-buffer-window (car list) 'visible)
! 	    (or notsogood (eq (car list) (current-buffer)))
! 	  (setq found (car list))))
!       (pop list))
!     (or found notsogood
! 	(get-buffer "*scratch*")
  	(progn
! 	  (set-buffer-major-mode
! 	   (get-buffer-create "*scratch*"))
  	  (get-buffer "*scratch*")))))
  
  (defun unbury-buffer () "\
--- 338,372 ----
  (defvar mode-line-buffer-identification-keymap nil "\
  Keymap for what is displayed by `mode-line-buffer-identification'.")
  
! (defun last-buffer (&optional buffer visible-ok frame) "\
! Return the last non-hidden buffer in the buffer list.
! If BUFFER is non-nil, last-buffer will ignore that buffer.
! Buffers not visible in windows are preferred to visible buffers,
! unless optional argument VISIBLE-OK is non-nil.
! If the optional third argument FRAME is non-nil, use that frame's
! buffer list instead of the selected frame's buffer list.
! If no other buffer exists, the buffer `*scratch*' is returned."
!   (setq frame (or frame (selected-frame)))
!   ;; This logic is more or less copied from other-buffer.
!   (let ((search-list
! 	 #'(lambda (list)
! 	     "Search LIST for a valid buffer to display."
! 	     (let ((pred (frame-parameter frame 'buffer-predicate))
! 		   found buf)
! 	       (while (and (not found) list)
! 		 (setq buf (car list))
! 		 (if (and (not (eq buffer buf))
! 			  (buffer-live-p buf)
! 			  (or (null pred) (funcall pred buf))
! 			  (not (eq (aref (buffer-name buf) 0) ?\s))
! 			  (or visible-ok (null (get-buffer-window buf 'visible))))
! 		     (setq found buf)
! 		   (setq list (cdr list))))
! 	       list))))
!     (or (car (funcall search-list (frame-parameter frame 'buried-buffer-list)))
! 	(car (funcall search-list (nreverse (buffer-list frame))))
  	(progn
! 	  (set-buffer-major-mode (get-buffer-create "*scratch*"))
  	  (get-buffer "*scratch*")))))
  
  (defun unbury-buffer () "\
***************
*** 673,680 ****
  
  (define-key global-map [?\C-x right] 'next-buffer)
  (define-key global-map [?\C-x C-right] 'next-buffer)
! (define-key global-map [?\C-x left] 'prev-buffer)
! (define-key global-map [?\C-x C-left] 'prev-buffer)
  
  (let ((map minibuffer-local-map))
    (define-key map "\en"   'next-history-element)
--- 681,688 ----
  
  (define-key global-map [?\C-x right] 'next-buffer)
  (define-key global-map [?\C-x C-right] 'next-buffer)
! (define-key global-map [?\C-x left] 'previous-buffer)
! (define-key global-map [?\C-x C-left] 'previous-buffer)
  
  (let ((map minibuffer-local-map))
    (define-key map "\en"   'next-history-element)
Index: lisp/menu-bar.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/menu-bar.el,v
retrieving revision 1.282
diff -u -3 -p -r1.282 menu-bar.el
*** lisp/menu-bar.el	19 Nov 2005 11:23:04 -0000	1.282
--- lisp/menu-bar.el	7 Dec 2005 14:46:48 -0000
***************
*** 1662,1671 ****
  			     "Next Buffer"
  			     'next-buffer
  			     :help "Switch to the \"next\" buffer in a cyclic order")
! 		       (list 'prev-buffer
  			     'menu-item
  			     "Previous Buffer"
! 			     'prev-buffer
  			     :help "Switch to the \"previous\" buffer in a cyclic order")
  		       (list 'select-named-buffer
  			     'menu-item
--- 1662,1671 ----
  			     "Next Buffer"
  			     'next-buffer
  			     :help "Switch to the \"next\" buffer in a cyclic order")
! 		       (list 'previous-buffer
  			     'menu-item
  			     "Previous Buffer"
! 			     'previous-buffer
  			     :help "Switch to the \"previous\" buffer in a cyclic order")
  		       (list 'select-named-buffer
  			     'menu-item
Index: lisp/simple.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/simple.el,v
retrieving revision 1.777
diff -u -3 -p -r1.777 simple.el
*** lisp/simple.el	4 Dec 2005 02:42:29 -0000	1.777
--- lisp/simple.el	7 Dec 2005 14:46:48 -0000
***************
*** 56,76 ****
    "Switch to the next buffer in cyclic order."
    (interactive)
    (let ((buffer (current-buffer)))
!     (switch-to-buffer (other-buffer buffer))
      (bury-buffer buffer)))
  
! (defun prev-buffer ()
    "Switch to the previous buffer in cyclic order."
    (interactive)
!   (let ((list (nreverse (buffer-list)))
! 	found)
!     (while (and (not found) list)
!       (let ((buffer (car list)))
! 	(if (and (not (get-buffer-window buffer))
! 		 (not (string-match "\\` " (buffer-name buffer))))
! 	    (setq found buffer)))
!       (setq list (cdr list)))
!     (switch-to-buffer found)))
  \f
  ;;; next-error support framework
  
--- 56,69 ----
    "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)))
! 
  \f
  ;;; next-error support framework
  
Index: src/alloc.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/alloc.c,v
retrieving revision 1.384
diff -u -3 -p -r1.384 alloc.c
*** src/alloc.c	30 Nov 2005 00:04:51 -0000	1.384
--- src/alloc.c	7 Dec 2005 14:46:48 -0000
***************
*** 5370,5375 ****
--- 5370,5376 ----
  	  mark_object (ptr->menu_bar_vector);
  	  mark_object (ptr->buffer_predicate);
  	  mark_object (ptr->buffer_list);
+ 	  mark_object (ptr->buried_buffer_list);
  	  mark_object (ptr->menu_bar_window);
  	  mark_object (ptr->tool_bar_window);
  	  mark_face_cache (ptr->face_cache);
Index: src/buffer.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/buffer.c,v
retrieving revision 1.496
diff -u -3 -p -r1.496 buffer.c
*** src/buffer.c	6 Dec 2005 07:37:47 -0000	1.496
--- src/buffer.c	7 Dec 2005 14:46:48 -0000
***************
*** 212,236 ****
       (frame)
       Lisp_Object frame;
  {
!   Lisp_Object framelist, general;
    general = Fmapcar (Qcdr, Vbuffer_alist);
  
    if (FRAMEP (frame))
      {
!       Lisp_Object tail;
  
        CHECK_FRAME (frame);
  
        framelist = Fcopy_sequence (XFRAME (frame)->buffer_list);
  
!       /* Remove from GENERAL any buffer that duplicates one in FRAMELIST.  */
        tail = framelist;
!       while (! NILP (tail))
  	{
  	  general = Fdelq (XCAR (tail), general);
  	  tail = XCDR (tail);
  	}
!       return nconc2 (framelist, general);
      }
  
    return general;
--- 212,249 ----
       (frame)
       Lisp_Object frame;
  {
!   Lisp_Object general;
    general = Fmapcar (Qcdr, Vbuffer_alist);
  
    if (FRAMEP (frame))
      {
!       Lisp_Object framelist, prevlist, tail;
!       Lisp_Object args[3];
  
        CHECK_FRAME (frame);
  
        framelist = Fcopy_sequence (XFRAME (frame)->buffer_list);
+       prevlist = Fcopy_sequence (XFRAME (frame)->buried_buffer_list);
  
!       /* Remove from GENERAL any buffer that duplicates one in
!          FRAMELIST or PREVLIST.  */
        tail = framelist;
!       while (CONSP (tail))
  	{
  	  general = Fdelq (XCAR (tail), general);
  	  tail = XCDR (tail);
  	}
!       tail = prevlist;
!       while (CONSP (tail))
! 	{
! 	  general = Fdelq (XCAR (tail), general);
! 	  tail = XCDR (tail);
! 	}
! 
!       args[0] = framelist;
!       args[1] = general;
!       args[2] = prevlist;
!       return Fnconc (3, args);
      }
  
    return general;
***************
*** 1545,1550 ****
--- 1558,1580 ----
    XSETCDR (link, Vbuffer_alist);
    Vbuffer_alist = link;
  
+   /* Effectively do a delq on buried_buffer_list.  */
+   
+   prev = Qnil;
+   for (link = XFRAME (frame)->buried_buffer_list; CONSP (link);
+        link = XCDR (link))
+     {
+       if (EQ (XCAR (link), buf))
+         {
+           if (NILP (prev))
+             XFRAME (frame)->buried_buffer_list = XCDR (link);
+           else
+             XSETCDR (prev, XCDR (XCDR (prev)));
+           break;
+         }
+       prev = link;
+     }
+ 
    /* Now move this buffer to the front of frame_buffer_list also.  */
  
    prev = Qnil;
***************
*** 2016,2025 ****
        XSETCDR (link, Qnil);
        Vbuffer_alist = nconc2 (Vbuffer_alist, link);
  
!       /* Removing BUFFER from frame-specific lists
! 	 has the effect of putting BUFFER at the end
! 	 of the combined list in each frame.  */
!       frames_discard_buffer (buffer);
      }
  
    return Qnil;
--- 2046,2055 ----
        XSETCDR (link, Qnil);
        Vbuffer_alist = nconc2 (Vbuffer_alist, link);
  
!       XFRAME (selected_frame)->buffer_list
!         = Fdelq (buffer, XFRAME (selected_frame)->buffer_list);
!       XFRAME (selected_frame)->buried_buffer_list
!         = Fcons (buffer, XFRAME (selected_frame)->buried_buffer_list);
      }
  
    return Qnil;
Index: src/frame.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/frame.c,v
retrieving revision 1.322
diff -u -3 -p -r1.322 frame.c
*** src/frame.c	10 Oct 2005 14:52:50 -0000	1.322
--- src/frame.c	7 Dec 2005 14:46:48 -0000
***************
*** 104,110 ****
  Lisp_Object Qunsplittable;
  Lisp_Object Qmenu_bar_lines, Qtool_bar_lines;
  Lisp_Object Qleft_fringe, Qright_fringe;
! Lisp_Object Qbuffer_predicate, Qbuffer_list;
  Lisp_Object Qtty_color_mode;
  
  Lisp_Object Qfullscreen, Qfullwidth, Qfullheight, Qfullboth;
--- 104,110 ----
  Lisp_Object Qunsplittable;
  Lisp_Object Qmenu_bar_lines, Qtool_bar_lines;
  Lisp_Object Qleft_fringe, Qright_fringe;
! Lisp_Object Qbuffer_predicate, Qbuffer_list, Qburied_buffer_list;
  Lisp_Object Qtty_color_mode;
  
  Lisp_Object Qfullscreen, Qfullwidth, Qfullheight, Qfullboth;
***************
*** 276,281 ****
--- 276,282 ----
    f->menu_bar_items_used = 0;
    f->buffer_predicate = Qnil;
    f->buffer_list = Qnil;
+   f->buried_buffer_list = Qnil;
  #ifdef MULTI_KBOARD
    f->kboard = initial_kboard;
  #endif
***************
*** 1900,1906 ****
    XFRAME (frame)->buffer_list = list;
  }
  
! /* Discard BUFFER from the buffer-list of each frame.  */
  
  void
  frames_discard_buffer (buffer)
--- 1901,1907 ----
    XFRAME (frame)->buffer_list = list;
  }
  
! /* Discard BUFFER from the buffer-list and buried-buffer-list of each frame.  */
  
  void
  frames_discard_buffer (buffer)
***************
*** 1912,1917 ****
--- 1913,1920 ----
      {
        XFRAME (frame)->buffer_list
  	= Fdelq (buffer, XFRAME (frame)->buffer_list);
+       XFRAME (frame)->buried_buffer_list
+         = Fdelq (buffer, XFRAME (frame)->buried_buffer_list);
      }
  }
  
***************
*** 1999,2011 ****
  {
    register Lisp_Object old_alist_elt;
  
!   /* The buffer-alist parameter is stored in a special place and is
!      not in the alist.  */
    if (EQ (prop, Qbuffer_list))
      {
        f->buffer_list = val;
        return;
      }
  
    /* If PROP is a symbol which is supposed to have frame-local values,
       and it is set up based on this frame, switch to the global
--- 2002,2019 ----
  {
    register Lisp_Object old_alist_elt;
  
!   /* The buffer-list parameters are stored in a special place and not
!      in the alist.  */
    if (EQ (prop, Qbuffer_list))
      {
        f->buffer_list = val;
        return;
      }
+   if (EQ (prop, Qburied_buffer_list))
+     {
+       f->buried_buffer_list = val;
+       return;
+     }
  
    /* If PROP is a symbol which is supposed to have frame-local values,
       and it is set up based on this frame, switch to the global
***************
*** 2145,2150 ****
--- 2153,2159 ----
  		   : FRAME_MINIBUF_WINDOW (f)));
    store_in_alist (&alist, Qunsplittable, (FRAME_NO_SPLIT_P (f) ? Qt : Qnil));
    store_in_alist (&alist, Qbuffer_list, frame_buffer_list (frame));
+   store_in_alist (&alist, Qburied_buffer_list, XFRAME (frame)->buried_buffer_list);
  
    /* I think this should be done with a hook.  */
  #ifdef HAVE_WINDOW_SYSTEM
***************
*** 3965,3970 ****
--- 3974,3981 ----
    staticpro (&Qbuffer_predicate);
    Qbuffer_list = intern ("buffer-list");
    staticpro (&Qbuffer_list);
+   Qburied_buffer_list = intern ("buried-buffer-list");
+   staticpro (&Qburied_buffer_list);
    Qdisplay_type = intern ("display-type");
    staticpro (&Qdisplay_type);
    Qbackground_mode = intern ("background-mode");
Index: src/frame.h
===================================================================
RCS file: /cvsroot/emacs/emacs/src/frame.h,v
retrieving revision 1.112
diff -u -3 -p -r1.112 frame.h
*** src/frame.h	8 Sep 2005 22:30:08 -0000	1.112
--- src/frame.h	7 Dec 2005 14:46:48 -0000
***************
*** 182,187 ****
--- 182,191 ----
    /* List of buffers viewed in this frame, for other-buffer.  */
    Lisp_Object buffer_list;
  
+   /* List of buffers that were viewed, then buried in this frame.  The
+      most recently buried buffer is first.  For previous-buffer.  */
+   Lisp_Object buried_buffer_list;
+   
    /* A dummy window used to display menu bars under X when no X
       toolkit support is available.  */
    Lisp_Object menu_bar_window;
***************
*** 994,1000 ****
  
  extern Lisp_Object Qauto_raise, Qauto_lower;
  extern Lisp_Object Qborder_color, Qborder_width;
! extern Lisp_Object Qbuffer_predicate, Qbuffer_list;
  extern Lisp_Object Qcursor_color, Qcursor_type;
  extern Lisp_Object Qfont;
  extern Lisp_Object Qbackground_color, Qforeground_color;
--- 998,1004 ----
  
  extern Lisp_Object Qauto_raise, Qauto_lower;
  extern Lisp_Object Qborder_color, Qborder_width;
! extern Lisp_Object Qbuffer_predicate, Qbuffer_list, Qburied_buffer_list;
  extern Lisp_Object Qcursor_color, Qcursor_type;
  extern Lisp_Object Qfont;
  extern Lisp_Object Qbackground_color, Qforeground_color;

[-- Attachment #1.1.3: Type: text/plain, Size: 15 bytes --]


-- 
Károly

[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Buffer listing in multiple frames/ttys

[Juri Linkov]

> I implemented this in the patch at the end of this message.
> It involves adding a new element to the frame struct, and changing
> switch-to-buffer, bury-buffer and kill-buffer etc. to maintain
> the list.

After looking at your patch it seems that everything will work correctly.
I will give your patch more testing and will report possible problems asap.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Buffer listing in multiple frames/ttys

[Juri Linkov]

Thanks for your patch.  Generally it works correctly, with few exceptions:

1. The function `buffer-list' returns a list of buried buffers in reverse
order.  In the frame parameter `buried_buffer_list' the most recently
buried buffer is first, so `buffer-list' misses a Fnreverse on `prevlist'.

2. Since `last-buffer' is a general function, I suggest to move it to
simple.el.

3. Could you create a separate function from lambda which is now let-bound
in `last-buffer'?  It could be named, for example, as `get-next-valid-buffer'.
Beside of the advantage of not messing with funcalls, it will be
useful outside `last-buffer'.  In .emacs I have a function defadviced
on `next-buffer' and `prev-buffer' that displays a list of two previous,
current and two next buffer names in the echo area after calling
`next-buffer' or `prev-buffer'.  The message looks like:

-2:*Messages* -1:*Help*    0:.emacs      1:*info*  2:*scratch*

It is useful to see what buffers will be visited on subsequent
invocation of `next-buffer' or `prev-buffer'.  This is like what
some window managers display during switching of windows.

If you create a new function from lambda then the code to put in .emacs
to display this message could be simplified to:

(defadvice previous-buffer (after my-previous-buffer activate)
  (my-display-prev-next-buffers))

(defadvice next-buffer (after my-next-buffer activate)
  (my-display-prev-next-buffers))

(defun my-display-prev-next-buffers ()
  "Show two previous, current and two next buffer names in the echo area."
  (interactive)
  (let ((i -3) b (bl (buffer-list (selected-frame))) (message-log-max nil))
    (message "%s"
             (mapconcat
              (lambda (x)
                (setq i (+ i 1))
                (format "%d:%-12s"
                        i (substring
                           (buffer-name x) 0 (min (length (buffer-name x)) 11))))
              (append
               (nreverse
                (list
                 (setq b (get-next-valid-buffer (reverse bl) t))
                 (get-next-valid-buffer (cdr (memq b (reverse bl))) t)))
               (list (current-buffer))
               (list
                (setq b (get-next-valid-buffer (cdr bl) t))
                (get-next-valid-buffer (cdr (memq b bl)) t)))
              " "))))

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Buffer listing in multiple frames/ttys

[Lőrentey Károly]

[-- Attachment #1.1.1: Type: text/plain, Size: 636 bytes --]

Juri Linkov <juri@jurta.org> writes:
> Thanks for your patch.  Generally it works correctly, with few exceptions:
>
> 1. The function `buffer-list' returns a list of buried buffers in reverse
> order.  In the frame parameter `buried_buffer_list' the most recently
> buried buffer is first, so `buffer-list' misses a Fnreverse on `prevlist'.

Fixed.

> 2. Since `last-buffer' is a general function, I suggest to move it to
> simple.el.

Done.

> 3. Could you create a separate function from lambda which is now let-bound
> in `last-buffer'?  It could be named, for example, as `get-next-valid-buffer'.

Done.  New patch attached below.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.1.2: Type: text/x-patch, Size: 15303 bytes --]

Index: lisp/bindings.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/bindings.el,v
retrieving revision 1.154
diff -u -3 -p -r1.154 bindings.el
*** lisp/bindings.el	28 Oct 2005 16:19:16 -0000	1.154
--- lisp/bindings.el	8 Dec 2005 14:22:42 -0000
***************
*** 338,366 ****
  (defvar mode-line-buffer-identification-keymap nil "\
  Keymap for what is displayed by `mode-line-buffer-identification'.")
  
- (defun last-buffer () "\
- Return the last non-hidden buffer in the buffer list."
-   ;; This logic is more or less copied from bury-buffer,
-   ;; except that we reverse the buffer list.
-   (let ((list (nreverse (buffer-list (selected-frame))))
- 	(pred (frame-parameter nil 'buffer-predicate))
- 	found notsogood)
-     (while (and list (not found))
-       (unless (or (eq (aref (buffer-name (car list)) 0) ? )
- 		  ;; If the selected frame has a buffer_predicate,
- 		  ;; disregard buffers that don't fit the predicate.
- 		  (and pred (not (funcall pred (car list)))))
- 	(if (get-buffer-window (car list) 'visible)
- 	    (or notsogood (eq (car list) (current-buffer)))
- 	  (setq found (car list))))
-       (pop list))
-     (or found notsogood
- 	(get-buffer "*scratch*")
- 	(progn
- 	  (set-buffer-major-mode
- 	   (get-buffer-create "*scratch*"))
- 	  (get-buffer "*scratch*")))))
- 
  (defun unbury-buffer () "\
  Switch to the last buffer in the buffer list."
    (interactive)
--- 338,343 ----
***************
*** 673,680 ****
  
  (define-key global-map [?\C-x right] 'next-buffer)
  (define-key global-map [?\C-x C-right] 'next-buffer)
! (define-key global-map [?\C-x left] 'prev-buffer)
! (define-key global-map [?\C-x C-left] 'prev-buffer)
  
  (let ((map minibuffer-local-map))
    (define-key map "\en"   'next-history-element)
--- 650,657 ----
  
  (define-key global-map [?\C-x right] 'next-buffer)
  (define-key global-map [?\C-x C-right] 'next-buffer)
! (define-key global-map [?\C-x left] 'previous-buffer)
! (define-key global-map [?\C-x C-left] 'previous-buffer)
  
  (let ((map minibuffer-local-map))
    (define-key map "\en"   'next-history-element)
Index: lisp/menu-bar.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/menu-bar.el,v
retrieving revision 1.282
diff -u -3 -p -r1.282 menu-bar.el
*** lisp/menu-bar.el	19 Nov 2005 11:23:04 -0000	1.282
--- lisp/menu-bar.el	8 Dec 2005 14:22:43 -0000
***************
*** 1662,1671 ****
  			     "Next Buffer"
  			     'next-buffer
  			     :help "Switch to the \"next\" buffer in a cyclic order")
! 		       (list 'prev-buffer
  			     'menu-item
  			     "Previous Buffer"
! 			     'prev-buffer
  			     :help "Switch to the \"previous\" buffer in a cyclic order")
  		       (list 'select-named-buffer
  			     'menu-item
--- 1662,1671 ----
  			     "Next Buffer"
  			     'next-buffer
  			     :help "Switch to the \"next\" buffer in a cyclic order")
! 		       (list 'previous-buffer
  			     'menu-item
  			     "Previous Buffer"
! 			     'previous-buffer
  			     :help "Switch to the \"previous\" buffer in a cyclic order")
  		       (list 'select-named-buffer
  			     'menu-item
Index: lisp/simple.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/simple.el,v
retrieving revision 1.777
diff -u -3 -p -r1.777 simple.el
*** lisp/simple.el	4 Dec 2005 02:42:29 -0000	1.777
--- lisp/simple.el	8 Dec 2005 14:22:43 -0000
***************
*** 52,76 ****
    "Highlight (un)matching of parens and expressions."
    :group 'matching)
  
  (defun next-buffer ()
    "Switch to the next buffer in cyclic order."
    (interactive)
    (let ((buffer (current-buffer)))
!     (switch-to-buffer (other-buffer buffer))
      (bury-buffer buffer)))
  
! (defun prev-buffer ()
    "Switch to the previous buffer in cyclic order."
    (interactive)
!   (let ((list (nreverse (buffer-list)))
! 	found)
!     (while (and (not found) list)
!       (let ((buffer (car list)))
! 	(if (and (not (get-buffer-window buffer))
! 		 (not (string-match "\\` " (buffer-name buffer))))
! 	    (setq found buffer)))
!       (setq list (cdr list)))
!     (switch-to-buffer found)))
  \f
  ;;; next-error support framework
  
--- 52,108 ----
    "Highlight (un)matching of parens and expressions."
    :group 'matching)
  
+ (defun get-next-valid-buffer (list &optional buffer visible-ok frame) "\
+ Search LIST for a valid buffer to display in FRAME.
+ Return nil when all buffers in LIST are undesirable for display,
+ otherwise return the first suitable buffer in LIST.
+ 
+ Buffers not visible in windows are preferred to visible buffers,
+ unless VISIBLE-OK is non-nil.
+ If the optional argument FRAME is nil, it defaults to the selected frame.
+ If BUFFER is non-nil, ignore occurances of that buffer in LIST."
+   ;; This logic is more or less copied from other-buffer.
+   (setq frame (or frame (selected-frame)))
+   (let ((pred (frame-parameter frame 'buffer-predicate))
+ 	found buf)
+     (while (and (not found) list)
+       (setq buf (car list))
+       (if (and (not (eq buffer buf))
+ 	       (buffer-live-p buf)
+ 	       (or (null pred) (funcall pred buf))
+ 	       (not (eq (aref (buffer-name buf) 0) ?\s))
+ 	       (or visible-ok (null (get-buffer-window buf 'visible))))
+ 	  (setq found buf)
+ 	(setq list (cdr list))))
+     (car list)))
+ 
+ (defun last-buffer (&optional buffer visible-ok frame) "\
+ Return the last non-hidden displayable buffer in the buffer list.
+ If BUFFER is non-nil, last-buffer will ignore that buffer.
+ Buffers not visible in windows are preferred to visible buffers,
+ unless optional argument VISIBLE-OK is non-nil.
+ If the optional third argument FRAME is non-nil, use that frame's
+ buffer list instead of the selected frame's buffer list.
+ If no other buffer exists, the buffer `*scratch*' is returned."
+   (setq frame (or frame (selected-frame)))
+   (or (get-next-valid-buffer (nreverse (buffer-list frame))
+ 			     buffer-visible-ok frame)
+       (progn
+ 	(set-buffer-major-mode (get-buffer-create "*scratch*"))
+ 	(get-buffer "*scratch*"))))
+ 
  (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)))
! 
  \f
  ;;; next-error support framework
  
Index: src/alloc.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/alloc.c,v
retrieving revision 1.384
diff -u -3 -p -r1.384 alloc.c
*** src/alloc.c	30 Nov 2005 00:04:51 -0000	1.384
--- src/alloc.c	8 Dec 2005 14:22:43 -0000
***************
*** 5370,5375 ****
--- 5370,5376 ----
  	  mark_object (ptr->menu_bar_vector);
  	  mark_object (ptr->buffer_predicate);
  	  mark_object (ptr->buffer_list);
+ 	  mark_object (ptr->buried_buffer_list);
  	  mark_object (ptr->menu_bar_window);
  	  mark_object (ptr->tool_bar_window);
  	  mark_face_cache (ptr->face_cache);
Index: src/buffer.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/buffer.c,v
retrieving revision 1.496
diff -u -3 -p -r1.496 buffer.c
*** src/buffer.c	6 Dec 2005 07:37:47 -0000	1.496
--- src/buffer.c	8 Dec 2005 14:22:43 -0000
***************
*** 212,236 ****
       (frame)
       Lisp_Object frame;
  {
!   Lisp_Object framelist, general;
    general = Fmapcar (Qcdr, Vbuffer_alist);
  
    if (FRAMEP (frame))
      {
!       Lisp_Object tail;
  
        CHECK_FRAME (frame);
  
        framelist = Fcopy_sequence (XFRAME (frame)->buffer_list);
  
!       /* Remove from GENERAL any buffer that duplicates one in FRAMELIST.  */
        tail = framelist;
!       while (! NILP (tail))
  	{
  	  general = Fdelq (XCAR (tail), general);
  	  tail = XCDR (tail);
  	}
!       return nconc2 (framelist, general);
      }
  
    return general;
--- 212,249 ----
       (frame)
       Lisp_Object frame;
  {
!   Lisp_Object general;
    general = Fmapcar (Qcdr, Vbuffer_alist);
  
    if (FRAMEP (frame))
      {
!       Lisp_Object framelist, prevlist, tail;
!       Lisp_Object args[3];
  
        CHECK_FRAME (frame);
  
        framelist = Fcopy_sequence (XFRAME (frame)->buffer_list);
+       prevlist = Fnreverse (Fcopy_sequence (XFRAME (frame)->buried_buffer_list));
  
!       /* Remove from GENERAL any buffer that duplicates one in
!          FRAMELIST or PREVLIST.  */
        tail = framelist;
!       while (CONSP (tail))
  	{
  	  general = Fdelq (XCAR (tail), general);
  	  tail = XCDR (tail);
  	}
!       tail = prevlist;
!       while (CONSP (tail))
! 	{
! 	  general = Fdelq (XCAR (tail), general);
! 	  tail = XCDR (tail);
! 	}
! 
!       args[0] = framelist;
!       args[1] = general;
!       args[2] = prevlist;
!       return Fnconc (3, args);
      }
  
    return general;
***************
*** 1545,1550 ****
--- 1558,1580 ----
    XSETCDR (link, Vbuffer_alist);
    Vbuffer_alist = link;
  
+   /* Effectively do a delq on buried_buffer_list.  */
+   
+   prev = Qnil;
+   for (link = XFRAME (frame)->buried_buffer_list; CONSP (link);
+        link = XCDR (link))
+     {
+       if (EQ (XCAR (link), buf))
+         {
+           if (NILP (prev))
+             XFRAME (frame)->buried_buffer_list = XCDR (link);
+           else
+             XSETCDR (prev, XCDR (XCDR (prev)));
+           break;
+         }
+       prev = link;
+     }
+ 
    /* Now move this buffer to the front of frame_buffer_list also.  */
  
    prev = Qnil;
***************
*** 2016,2025 ****
        XSETCDR (link, Qnil);
        Vbuffer_alist = nconc2 (Vbuffer_alist, link);
  
!       /* Removing BUFFER from frame-specific lists
! 	 has the effect of putting BUFFER at the end
! 	 of the combined list in each frame.  */
!       frames_discard_buffer (buffer);
      }
  
    return Qnil;
--- 2046,2055 ----
        XSETCDR (link, Qnil);
        Vbuffer_alist = nconc2 (Vbuffer_alist, link);
  
!       XFRAME (selected_frame)->buffer_list
!         = Fdelq (buffer, XFRAME (selected_frame)->buffer_list);
!       XFRAME (selected_frame)->buried_buffer_list
!         = Fcons (buffer, XFRAME (selected_frame)->buried_buffer_list);
      }
  
    return Qnil;
Index: src/frame.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/frame.c,v
retrieving revision 1.322
diff -u -3 -p -r1.322 frame.c
*** src/frame.c	10 Oct 2005 14:52:50 -0000	1.322
--- src/frame.c	8 Dec 2005 14:22:43 -0000
***************
*** 104,110 ****
  Lisp_Object Qunsplittable;
  Lisp_Object Qmenu_bar_lines, Qtool_bar_lines;
  Lisp_Object Qleft_fringe, Qright_fringe;
! Lisp_Object Qbuffer_predicate, Qbuffer_list;
  Lisp_Object Qtty_color_mode;
  
  Lisp_Object Qfullscreen, Qfullwidth, Qfullheight, Qfullboth;
--- 104,110 ----
  Lisp_Object Qunsplittable;
  Lisp_Object Qmenu_bar_lines, Qtool_bar_lines;
  Lisp_Object Qleft_fringe, Qright_fringe;
! Lisp_Object Qbuffer_predicate, Qbuffer_list, Qburied_buffer_list;
  Lisp_Object Qtty_color_mode;
  
  Lisp_Object Qfullscreen, Qfullwidth, Qfullheight, Qfullboth;
***************
*** 276,281 ****
--- 276,282 ----
    f->menu_bar_items_used = 0;
    f->buffer_predicate = Qnil;
    f->buffer_list = Qnil;
+   f->buried_buffer_list = Qnil;
  #ifdef MULTI_KBOARD
    f->kboard = initial_kboard;
  #endif
***************
*** 1900,1906 ****
    XFRAME (frame)->buffer_list = list;
  }
  
! /* Discard BUFFER from the buffer-list of each frame.  */
  
  void
  frames_discard_buffer (buffer)
--- 1901,1907 ----
    XFRAME (frame)->buffer_list = list;
  }
  
! /* Discard BUFFER from the buffer-list and buried-buffer-list of each frame.  */
  
  void
  frames_discard_buffer (buffer)
***************
*** 1912,1917 ****
--- 1913,1920 ----
      {
        XFRAME (frame)->buffer_list
  	= Fdelq (buffer, XFRAME (frame)->buffer_list);
+       XFRAME (frame)->buried_buffer_list
+         = Fdelq (buffer, XFRAME (frame)->buried_buffer_list);
      }
  }
  
***************
*** 1999,2011 ****
  {
    register Lisp_Object old_alist_elt;
  
!   /* The buffer-alist parameter is stored in a special place and is
!      not in the alist.  */
    if (EQ (prop, Qbuffer_list))
      {
        f->buffer_list = val;
        return;
      }
  
    /* If PROP is a symbol which is supposed to have frame-local values,
       and it is set up based on this frame, switch to the global
--- 2002,2019 ----
  {
    register Lisp_Object old_alist_elt;
  
!   /* The buffer-list parameters are stored in a special place and not
!      in the alist.  */
    if (EQ (prop, Qbuffer_list))
      {
        f->buffer_list = val;
        return;
      }
+   if (EQ (prop, Qburied_buffer_list))
+     {
+       f->buried_buffer_list = val;
+       return;
+     }
  
    /* If PROP is a symbol which is supposed to have frame-local values,
       and it is set up based on this frame, switch to the global
***************
*** 2145,2150 ****
--- 2153,2159 ----
  		   : FRAME_MINIBUF_WINDOW (f)));
    store_in_alist (&alist, Qunsplittable, (FRAME_NO_SPLIT_P (f) ? Qt : Qnil));
    store_in_alist (&alist, Qbuffer_list, frame_buffer_list (frame));
+   store_in_alist (&alist, Qburied_buffer_list, XFRAME (frame)->buried_buffer_list);
  
    /* I think this should be done with a hook.  */
  #ifdef HAVE_WINDOW_SYSTEM
***************
*** 3965,3970 ****
--- 3974,3981 ----
    staticpro (&Qbuffer_predicate);
    Qbuffer_list = intern ("buffer-list");
    staticpro (&Qbuffer_list);
+   Qburied_buffer_list = intern ("buried-buffer-list");
+   staticpro (&Qburied_buffer_list);
    Qdisplay_type = intern ("display-type");
    staticpro (&Qdisplay_type);
    Qbackground_mode = intern ("background-mode");
Index: src/frame.h
===================================================================
RCS file: /cvsroot/emacs/emacs/src/frame.h,v
retrieving revision 1.112
diff -u -3 -p -r1.112 frame.h
*** src/frame.h	8 Sep 2005 22:30:08 -0000	1.112
--- src/frame.h	8 Dec 2005 14:22:43 -0000
***************
*** 182,187 ****
--- 182,191 ----
    /* List of buffers viewed in this frame, for other-buffer.  */
    Lisp_Object buffer_list;
  
+   /* List of buffers that were viewed, then buried in this frame.  The
+      most recently buried buffer is first.  For last-buffer.  */
+   Lisp_Object buried_buffer_list;
+   
    /* A dummy window used to display menu bars under X when no X
       toolkit support is available.  */
    Lisp_Object menu_bar_window;
***************
*** 994,1000 ****
  
  extern Lisp_Object Qauto_raise, Qauto_lower;
  extern Lisp_Object Qborder_color, Qborder_width;
! extern Lisp_Object Qbuffer_predicate, Qbuffer_list;
  extern Lisp_Object Qcursor_color, Qcursor_type;
  extern Lisp_Object Qfont;
  extern Lisp_Object Qbackground_color, Qforeground_color;
--- 998,1004 ----
  
  extern Lisp_Object Qauto_raise, Qauto_lower;
  extern Lisp_Object Qborder_color, Qborder_width;
! extern Lisp_Object Qbuffer_predicate, Qbuffer_list, Qburied_buffer_list;
  extern Lisp_Object Qcursor_color, Qcursor_type;
  extern Lisp_Object Qfont;
  extern Lisp_Object Qbackground_color, Qforeground_color;

[-- Attachment #1.1.3: Type: text/plain, Size: 16 bytes --]


-- 
Károly

[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Buffer listing in multiple frames/ttys

[Richard M. Stallman]

    Ah, good idea.  I implemented this in the patch at the end of this
    message.  It involves adding a new element to the frame struct, and
    changing switch-to-buffer, bury-buffer and kill-buffer etc. to
    maintain the list.

This might be a good change, but at this point we want to avoid making
such far-reaching changes.  Let's look for a less radical change that
would result in some sort of consistent behavior.

Re: Buffer listing in multiple frames/ttys

[Juri Linkov]

>     Ah, good idea.  I implemented this in the patch at the end of this
>     message.  It involves adding a new element to the frame struct, and
>     changing switch-to-buffer, bury-buffer and kill-buffer etc. to
>     maintain the list.
>
> This might be a good change, but at this point we want to avoid making
> such far-reaching changes.  Let's look for a less radical change that
> would result in some sort of consistent behavior.

Could you suggest another way of maintaining a frame-local list of
buried buffers (buffers at the bottom of the frame-local buffer list
accessible for cycling via `previous-buffer')?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Buffer listing in multiple frames/ttys

[Richard M. Stallman]

    Could you suggest another way of maintaining a frame-local list of
    buried buffers (buffers at the bottom of the frame-local buffer list
    accessible for cycling via `previous-buffer')?

It could be an ordinary frame parameter, if only previous-buffer will
access it.  But I don't like the idea of changing primitives such as
switch-to-buffer, bury-buffer, and kill-buffer.  Not now.

Perhaps it is better if next-buffer and previous-buffer simply use the
global buffer list.  It is not worth changing those primitives now just
make a feature work in a slightly better way.

Re: Buffer listing in multiple frames/ttys

[Lőrentey Károly]

[-- Attachment #1.1: Type: text/plain, Size: 345 bytes --]

Richard Stallman <rms@gnu.org> writes:
> But I don't like the idea of changing primitives such as
> switch-to-buffer, bury-buffer, and kill-buffer.  Not now.

Fair enough.  I'll clean up and repost my last patch that did not have
such low-level changes.  We'll have ample time to discuss a complete
fix after the release.

-- 
Károly

[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Buffer listing in multiple frames/ttys

[Juri Linkov]

> I'll clean up and repost my last patch that did not have such
> low-level changes.

But please don't change next-buffer to use the global buffer list.

> We'll have ample time to discuss a complete fix after the release.

I guess this time is during merging the multi-tty branch into the trunk?  Ok.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Buffer listing in multiple frames/ttys

[Richard M. Stallman]

    > I'll clean up and repost my last patch that did not have such
    > low-level changes.

    But please don't change next-buffer to use the global buffer list.

    > We'll have ample time to discuss a complete fix after the release.

    I guess this time is during merging the multi-tty branch into the trunk?  Ok.

I thought we were talking about the trunk.

If this change is only for the multi-tty branch, I don't mind
adding a new element to the frame struct in that branch.

Is there a problem with these commands in the trunk?
That is the issue we should focus on now.

Re: Buffer listing in multiple frames/ttys

[Juri Linkov]

>     > I'll clean up and repost my last patch that did not have such
>     > low-level changes.
>
>     But please don't change next-buffer to use the global buffer list.
>
>     > We'll have ample time to discuss a complete fix after the release.
>
>     I guess this time is during merging the multi-tty branch into the trunk?  Ok.
>
> I thought we were talking about the trunk.

Yes, we were talking about the trunk.  Any radical changes in the
trunk could be postponed to the time after the next release.

> If this change is only for the multi-tty branch, I don't mind
> adding a new element to the frame struct in that branch.
>
> Is there a problem with these commands in the trunk?
> That is the issue we should focus on now.

There is the same problem in the trunk, but AFAIU you don't want
making radical changes in low-level functions in the trunk now.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Buffer listing in multiple frames/ttys

[Richard M. Stallman]

    > Is there a problem with these commands in the trunk?
    > That is the issue we should focus on now.

    There is the same problem in the trunk, but AFAIU you don't want
    making radical changes in low-level functions in the trunk now.

There is more than one way to solve the problem.  For the trunk
I want a solution that is less radical.

Re: Buffer listing in multiple frames/ttys

[Károly Lőrentey]

[-- Attachment #1.1: Type: text/plain, Size: 513 bytes --]

Richard Stallman <rms@gnu.org> writes:
> I thought we were talking about the trunk.

I thought so as well.

> If this change is only for the multi-tty branch, I don't mind
> adding a new element to the frame struct in that branch.

OK, then I'll apply the complete fix there.  The incomplete (but
Lisp-level) fix should definitely go in the trunk, though.

> Is there a problem with these commands in the trunk?

Yes: `next-buffer' and `previous-buffer' should behave frame-locally.

-- 
Károly

[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Buffer listing in multiple frames/ttys

[Károly Lőrentey]

[-- Attachment #1.1.1: Type: text/plain, Size: 380 bytes --]

Richard Stallman <rms@gnu.org> writes:
> It could be an ordinary frame parameter, if only previous-buffer will
> access it.  But I don't like the idea of changing primitives such as
> switch-to-buffer, bury-buffer, and kill-buffer.  Not now.

Below is an updated version of the patch without such low-level
changes.  If people find no problems, I'll install it on the CVS
trunk.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.1.2: Type: text/x-patch, Size: 6368 bytes --]

*** orig/lisp/bindings.el
--- mod/lisp/bindings.el
***************
*** 338,366 ****
  (defvar mode-line-buffer-identification-keymap nil "\
  Keymap for what is displayed by `mode-line-buffer-identification'.")
  
- (defun last-buffer () "\
- Return the last non-hidden buffer in the buffer list."
-   ;; This logic is more or less copied from bury-buffer,
-   ;; except that we reverse the buffer list.
-   (let ((list (nreverse (buffer-list (selected-frame))))
- 	(pred (frame-parameter nil 'buffer-predicate))
- 	found notsogood)
-     (while (and list (not found))
-       (unless (or (eq (aref (buffer-name (car list)) 0) ? )
- 		  ;; If the selected frame has a buffer_predicate,
- 		  ;; disregard buffers that don't fit the predicate.
- 		  (and pred (not (funcall pred (car list)))))
- 	(if (get-buffer-window (car list) 'visible)
- 	    (or notsogood (eq (car list) (current-buffer)))
- 	  (setq found (car list))))
-       (pop list))
-     (or found notsogood
- 	(get-buffer "*scratch*")
- 	(progn
- 	  (set-buffer-major-mode
- 	   (get-buffer-create "*scratch*"))
- 	  (get-buffer "*scratch*")))))
- 
  (defun unbury-buffer () "\
  Switch to the last buffer in the buffer list."
    (interactive)
--- 338,343 ----
***************
*** 673,680 ****
  
  (define-key global-map [?\C-x right] 'next-buffer)
  (define-key global-map [?\C-x C-right] 'next-buffer)
! (define-key global-map [?\C-x left] 'prev-buffer)
! (define-key global-map [?\C-x C-left] 'prev-buffer)
  
  (let ((map minibuffer-local-map))
    (define-key map "\en"   'next-history-element)
--- 650,657 ----
  
  (define-key global-map [?\C-x right] 'next-buffer)
  (define-key global-map [?\C-x C-right] 'next-buffer)
! (define-key global-map [?\C-x left] 'previous-buffer)
! (define-key global-map [?\C-x C-left] 'previous-buffer)
  
  (let ((map minibuffer-local-map))
    (define-key map "\en"   'next-history-element)


*** orig/lisp/menu-bar.el
--- mod/lisp/menu-bar.el
***************
*** 1662,1671 ****
  			     "Next Buffer"
  			     'next-buffer
  			     :help "Switch to the \"next\" buffer in a cyclic order")
! 		       (list 'prev-buffer
  			     'menu-item
  			     "Previous Buffer"
! 			     'prev-buffer
  			     :help "Switch to the \"previous\" buffer in a cyclic order")
  		       (list 'select-named-buffer
  			     'menu-item
--- 1662,1671 ----
  			     "Next Buffer"
  			     'next-buffer
  			     :help "Switch to the \"next\" buffer in a cyclic order")
! 		       (list 'previous-buffer
  			     'menu-item
  			     "Previous Buffer"
! 			     'previous-buffer
  			     :help "Switch to the \"previous\" buffer in a cyclic order")
  		       (list 'select-named-buffer
  			     'menu-item


*** orig/lisp/simple.el
--- mod/lisp/simple.el
***************
*** 52,75 ****
    "Highlight (un)matching of parens and expressions."
    :group 'matching)
  
  (defun next-buffer ()
    "Switch to the next buffer in cyclic order."
    (interactive)
!   (let ((buffer (current-buffer)))
!     (switch-to-buffer (other-buffer buffer))
!     (bury-buffer buffer)))
  
! (defun prev-buffer ()
    "Switch to the previous buffer in cyclic order."
    (interactive)
!   (let ((list (nreverse (buffer-list)))
! 	found)
!     (while (and (not found) list)
!       (let ((buffer (car list)))
! 	(if (and (not (get-buffer-window buffer))
! 		 (not (string-match "\\` " (buffer-name buffer))))
! 	    (setq found buffer)))
!       (setq list (cdr list)))
!     (switch-to-buffer found)))
  \f
  ;;; next-error support framework
--- 52,118 ----
    "Highlight (un)matching of parens and expressions."
    :group 'matching)
  
+ (defun get-next-valid-buffer (list &optional buffer visible-ok frame) "\
+ Search LIST for a valid buffer to display in FRAME.
+ Return nil when all buffers in LIST are undesirable for display,
+ otherwise return the first suitable buffer in LIST.
+ 
+ Buffers not visible in windows are preferred to visible buffers,
+ unless VISIBLE-OK is non-nil.
+ If the optional argument FRAME is nil, it defaults to the selected frame.
+ If BUFFER is non-nil, ignore occurances of that buffer in LIST."
+   ;; This logic is more or less copied from other-buffer.
+   (setq frame (or frame (selected-frame)))
+   (let ((pred (frame-parameter frame 'buffer-predicate))
+ 	found buf)
+     (while (and (not found) list)
+       (setq buf (car list))
+       (if (and (not (eq buffer buf))
+ 	       (buffer-live-p buf)
+ 	       (or (null pred) (funcall pred buf))
+ 	       (not (eq (aref (buffer-name buf) 0) ?\s))
+ 	       (or visible-ok (null (get-buffer-window buf 'visible))))
+ 	  (setq found buf)
+ 	(setq list (cdr list))))
+     (car list)))
+ 
+ (defun last-buffer (&optional buffer visible-ok frame) "\
+ Return the last non-hidden displayable buffer in the buffer list.
+ If BUFFER is non-nil, last-buffer will ignore that buffer.
+ Buffers not visible in windows are preferred to visible buffers,
+ unless optional argument VISIBLE-OK is non-nil.
+ If the optional third argument FRAME is non-nil, use that frame's
+ buffer list instead of the selected frame's buffer list.
+ If no other buffer exists, the buffer `*scratch*' is returned."
+   (setq frame (or frame (selected-frame)))
+   (or (get-next-valid-buffer (frame-parameter frame 'buried-buffer-list)
+ 			     buffer visible-ok frame)
+       (get-next-valid-buffer (nreverse (buffer-list frame))
+ 			     buffer-visible-ok frame)
+       (progn
+ 	(set-buffer-major-mode (get-buffer-create "*scratch*"))
+ 	(get-buffer "*scratch*"))))
+ 
  (defun next-buffer ()
    "Switch to the next buffer in cyclic order."
    (interactive)
!   (let ((buffer (current-buffer))
! 	(bbl (frame-parameter nil 'buried-buffer-list)))
!     (switch-to-buffer (other-buffer buffer t))
!     (bury-buffer buffer)
!     (set-frame-parameter nil 'buried-buffer-list
! 			 (cons buffer (delq buffer bbl)))))
  
! (defun previous-buffer ()
    "Switch to the previous buffer in cyclic order."
    (interactive)
!   (let ((buffer (last-buffer (current-buffer) t))
! 	(bbl (frame-parameter nil 'buried-buffer-list)))
!     (switch-to-buffer buffer)
!     ;; Clean up buried-buffer-list up to and including the chosen buffer.
!     (while (and bbl (not (eq (car bbl) buffer)))
!       (setq bbl (cdr bbl)))
!     (set-frame-parameter nil 'buried-buffer-list bbl)))
! 
  \f
  ;;; next-error support framework

[-- Attachment #1.1.3: Type: text/plain, Size: 16 bytes --]


-- 
Károly

[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Buffer listing in multiple frames/ttys

[Richard M. Stallman]

    Below is an updated version of the patch without such low-level
    changes.  If people find no problems, I'll install it on the CVS
    trunk.

Ok, and thanks.

When you do it, could you update etc/NEWS and the Emacs Manual?

Re: Buffer listing in multiple frames/ttys

[Károly Lőrentey]

[-- Attachment #1.1: Type: text/plain, Size: 327 bytes --]

Richard Stallman <rms@gnu.org> writes:
>     Below is an updated version of the patch without such low-level
>     changes.  If people find no problems, I'll install it on the CVS
>     trunk.
>
> Ok, and thanks.
>
> When you do it, could you update etc/NEWS and the Emacs Manual?

Yes, I'll do that.

-- 
Károly

[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Buffer listing in multiple frames/ttys

[Juri Linkov]

> Below is an updated version of the patch without such low-level
> changes.  If people find no problems, I'll install it on the CVS
> trunk.

I've tested your new version with Lisp changes (for the trunk).  I think
it is very good that you still use the new frame parameter at Lisp level
in next-buffer/previous-buffer.  At least this will produce correct
results while cycling buffers only with next-buffer/previous-buffer.
In some packages next-buffer could be even used as a replacement of `q'
sometimes.

I still have mixed feelings about changing the default behavior of
next-buffer/previous-buffer to always visit visible buffers (i.e.
using the argument `visible-ok').  I don't know what is more preferable.
When I have the same buffer in two window initially, then I wish
next-buffer and subsequent previous-buffer return to the same buffer.
When initially there are two different buffers in two windows, then
it's better to ignore visible-ok.  Maybe there should be two separate
command for every direction: `next-buffer' and `next-visible-buffer',
`previous-buffer' and `previous-visible-buffer'?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Buffer listing in multiple frames/ttys

[Richard M. Stallman]

    I appended to the end of this message enhanced versions of
    `next-buffer' and `prev-buffer' that eliminate this problem by
    maintaining a new auxiliary frame-local buffer list, called
    `previous-buffer-list'.  `next-buffer' prepends the old buffer to this
    list, and `prev-buffer' searches this list first; otherwise the two
    functions behave as in CVS.

That seems to fix the bug.  However, it seems that there are different
ideas of what is the right behavior in the multi-frame case.  I would
not mind having an option for that.

Re: Buffer listing in multiple frames/ttys

[Károly Lőrentey]

[-- Attachment #1.1: Type: text/plain, Size: 780 bytes --]

Richard Stallman <rms@gnu.org> writes:
>     I appended to the end of this message enhanced versions of
>     `next-buffer' and `prev-buffer' that eliminate this problem by
>     maintaining a new auxiliary frame-local buffer list, called
>     `previous-buffer-list'.  `next-buffer' prepends the old buffer to this
>     list, and `prev-buffer' searches this list first; otherwise the two
>     functions behave as in CVS.
>
> That seems to fix the bug.  However, it seems that there are different
> ideas of what is the right behavior in the multi-frame case.  I would
> not mind having an option for that.

The function `other-buffer' already uses a frame-local buffer list.
If a new option is desired, then `other-buffer' should use it as
well.

-- 
Károly

[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Buffer listing in multiple frames/ttys

[Richard M. Stallman]

    > That seems to fix the bug.  However, it seems that there are different
    > ideas of what is the right behavior in the multi-frame case.  I would
    > not mind having an option for that.

    The function `other-buffer' already uses a frame-local buffer list.
    If a new option is desired, then `other-buffer' should use it as
    well.

Now is not the time to start adding more arguments to lots of
functions.  Let's look for an approach that does not require this.

RE: Buffer listing in multiple frames/ttys

[Drew Adams]

    The following definitions change `prev-buffer' and `next-buffer' to
    follow the frame-local buffer ordering instead of the global
    `buffer-list'.
    
    Now, I like these definitions as it makes more sense for me to keep
    the buffer cycle frame-local, but they do have one disadvantage: the
    `next-buffer'/`prev-buffer' cycle will not usually contain all
    buffers---just those that were displayed in the current frame.  To
    reach the rest, the user needs to use `switch-to-buffer', or
    equivalent.
    
I may have misunderstood (I have not been following the latest part of this thread closely), but IIUC this would, for the same reasons discussed earlier, be inappropriate for many of us who use pop-up-frames = t. 

I don't really care, for myself, as I am unlikely to use next-buffer/prev-buffer, but I think it could be important for others who do want to use those commands with the one-buffer-per-frame-by-default behavior of pop-up-frames = t.

Re: Buffer listing in multiple frames/ttys

[Lőrentey Károly]

Drew Adams <drew.adams@oracle.com> writes:
> I may have misunderstood (I have not been following the latest part
> of this thread closely), but IIUC this would, for the same reasons
> discussed earlier, be inappropriate for many of us who use
> pop-up-frames = t.

Well, if you say so, then we should make it optional.  I would really
prefer not to introduce yet another user option for this, though.
Therefore I suggest that we reuse the new
`Buffer-menu-use-frame-buffer-list' option for this as well.  (After
renaming it to something generic, say, `use-frame-buffer-list'.)
There is little reason to keep them separate.

-- 
Károly

RE: Buffer listing in multiple frames/ttys

[Drew Adams]

    > I may have misunderstood (I have not been following the latest part
    > of this thread closely), but IIUC this would, for the same reasons
    > discussed earlier, be inappropriate for many of us who use
    > pop-up-frames = t.

    we should make it optional.  I would really prefer not to
    introduce yet another user option for this, though. Therefore
    I suggest that we reuse the new `Buffer-menu-use-frame-buffer-list'
    option for this as well.  (After renaming it to something generic,
    say, `use-frame-buffer-list'.) There is little reason to keep them
    separate.

Yes, it would be reasonable to use the same option.

I'd repeat, though, that it would make sense for the default value of the
option to come from the value of pop-up-frames:

        I still believe that most people who use pop-up-frames = t will
        want to set this option to nil (so, they would prefer that that
        behavior be the default for non-nil pop-up-frames), but I don't
        mind setting the option to get the old behavior.

That way, people who use one-buffer-per-frame-by-default would not need to
change anything, beyond setting pop-up-frames = t. I think that covers most
(but not all) people who set pop-up-frames = t.

Re: Buffer listing in multiple frames/ttys

[Juri Linkov]

> I'd repeat, though, that it would make sense for the default value of the
> option to come from the value of pop-up-frames:
>
>         I still believe that most people who use pop-up-frames = t will
>         want to set this option to nil (so, they would prefer that that
>         behavior be the default for non-nil pop-up-frames), but I don't
>         mind setting the option to get the old behavior.
>
> That way, people who use one-buffer-per-frame-by-default would not need to
> change anything, beyond setting pop-up-frames = t. I think that covers most
> (but not all) people who set pop-up-frames = t.

I still don't understand the need for a new option for one-buffer-per-frame
configuration.  When a new frame is created due to pop-up-frames=t, its
frame-local buffer-list contains exactly one buffer which is the current
buffer.  So (buffer-list) is an exact equivalent of (buffer-list t).

-- 
Juri Linkov
http://www.jurta.org/emacs/

RE: Buffer listing in multiple frames/ttys

[Drew Adams]

    > I'd repeat, though, that it would make sense for the default
    > value of the option to come from the value of pop-up-frames:
    >
    >         I still believe that most people who use
    >         pop-up-frames = t will want to set this option
    >         to nil (so, they would prefer that that
    >         behavior be the default for non-nil pop-up-frames),
    >         but I don't
    >         mind setting the option to get the old behavior.
    >
    > That way, people who use one-buffer-per-frame-by-default
    > would not need to change anything, beyond setting
    > pop-up-frames = t. I think that covers most
    > (but not all) people who set pop-up-frames = t.

    I still don't understand the need for a new option for
    one-buffer-per-frame
    configuration.  When a new frame is created due to pop-up-frames=t, its
    frame-local buffer-list contains exactly one buffer which is the current
    buffer.  So (buffer-list) is an exact equivalent of (buffer-list t).

I have trouble following this thread, because there are apparently multiple
changes being made now, some of which are bug fixes. The original discussion
that interested me concerned the problem of using the frame-local buffer
list, instead of the global list, for Buffer Menu. One bug involved
inappropriate additions to a frame's local buffer list. I don't know if
fixing that bug takes care of my concern or not - frankly, I'm a bit lost
now.

I believe that Karoly is on top of it all, however. He understands my
original concern, so I'm sure he'll DTRT wrt pop-up-frames. I'm OK with
whatever is done to take my original concern into account. IOW, I don't care
if there is a new option to take care of it, or a bug fix, or whatever it
takes. I just don't want the order of the buffers in the Buffer Menu to
change drastically, depending on which buffer (frame) I call it from. I
would like to be able to treat the Buffer Menu's chronological sort as a
global ordering, which ignores the frame residence of buffers altogether.

WRT one-buffer-per-frame: I mentioned one-buffer-per-frame-_by-default_. I
do change buffers in a given frame, so the local buffer list does change.
The behavior I described is generally one buffer _at a time_ per frame (but
I do occasionally use more than one window (buffer) at a time). In any case,
I never care about the different chronological buffer orderings in different
frames.

RE: Buffer listing in multiple frames/ttys

[Drew Adams]

    >  C-x C-b from various buffers
    > Perhaps there is a bug in the buffer list for each frame - or
    > perhaps the doc (Info) is not clear? When I do (frame-parameter
    > (selected-frame) 'buffer-list) in the different frames, each is a
    > list of multiple buffers (in spite of pop-up-frames forcing one
    > buffer per frame), and they are in different orders.
    
    I think I have found the problem.  When you use C-x 4 C-f, the new
    buffer gets displayed by `pop-to-buffer', and that function records
    the newly created buffer in the buffer list of the existing frame as
    well as the new frame.  This is clearly not right.
    
    I removed the duplicate call to record_buffer in CVS.

Thanks.