Re: Buffer listing in multiple frames/ttys

[lorentey@elte.hu (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