RE: Buffer listing in multiple frames/ttys

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

      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.