RE: Buffer listing in multiple frames/ttys

["Drew Adams" <drew.adams@oracle.com>]

    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