Re: `buffer-list' and the frame-parameter `buffer-predicate'

[Kai Großjohann]

Richard Stallman <address@hidden> writes:

> Now I understand.  The idea of limiting which buffers you can switch
> to is not the issue, I think.  What you want to do is limit that
> buffers are included in lists that are shown or offered to you.
>
> It should be easy to do as a customization that by writing
> replacements for the buffer menu commands, for list-buffers, and for
> switch-to-buffer (supplying a different list for completion, perhaps).
> I suggest you give these commands new names and bind them to keys as
> you see fit.  That is cleaner than redefiniting the standard
> functions.

I think this is not the right solution, as there are a lot of
functions that list buffers (either as completions, like
switch-to-buffer, or as a menu, like buffer-menu).  It would be a lot
of work to change all of them, and if each one is changed
individually, the behaviors are wont to be slightly different for
each one.

For example, switch-to-buffer doesn't offer a buffer as the default
that has only been selected in another frame, but buffer-menu does.
(Most of the time, C-x b RET and M-x buffer-menu RET n RET switch to
the same buffer, but with switch-to-buffer avoiding buffers which
have been selected in another frame, the behavior becomes different.)

There should be a single function that returns the list of buffers to
be used for switching to another buffer, and all functions for
switching buffers should use this function.  Then there is one spot
to tweak in order to tweak the switching behavior.

Oliver can use this for his "frames as workspaces" idea (which is
great), and I could use this to cleanly implement flobl.el.  (This
stands for frame-local buffer list and it means that switching to a
buffer in frame X does not change the order of buffers in frame Y.)

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)