bug#12081: 24.1; buffer-predicate often not called

[Dave Abrahams]

on Tue Jul 31 2012, martin rudalics <rudalics-AT-gmx.at> wrote:

>> When I kill a buffer in a particular workgroup, I want the replacement
>> buffer to be one that appeared recently in that workgroup, rather than
>> just something that's been seen recently in this frame.
>
> So a workgroup specifies a subset of all live buffers and the
> buffer-predicate you run on any of the buffers `switch-to-prev-buffer'
> proposes, sanctions the argument buffer iff it's part of that workgroup.
> Is that correct?

Almost.  When a buffer is displayed, it is associated with the current
workgroup via a buffer-local variable.  The buffer-predicate returns
true for any buffer associated with the current workgroup and returns
false for any others.

> This gives you little space in choosing the most suitable buffer from
> that workgroup.  

True.  I figure Emacs already has a heuristic for "most suitable," and
I just want it to apply that to the set of buffers whose last appearance
was in the current workgroup.

> Wouldn't it make more sense to provide a
> `switch-to-prev-buffer-function' with the window as argument and, if
> that function returns a live buffer which is not the same as the
> window's current buffer, use that buffer to replace the current one?
>
> Or maybe better: Give each window a `prev-buffer' window parameter such
> that
>
> (1) if it is a function, have `switch-to-prev-buffer' call that function
>     and use its return value (in your case, the function would choose
>     the buffer from the workgroup),
>
> (2) if it is a regexp or a list of buffers or names, try to use that
>     list for determining the buffer to switch to (in your case, that
>     list would be the buffers of the workgroup sorted acording to some
>     criteria).  If a buffer name in that list has no associated buffer,
>     `switch-to-prev-buffer' could create one if needed.

Well, yeah, all these things make sense if you're going to go so far as
to redesign or extend Emacs itself.  I was looking for a less-intrusive
solution, and to me, it seemed that the buffer predicate was simply not
working as it was supposed to.

>> Yes, I realized that only after I had implemented this.  But as
>> mentioned elsewhere:
>>
>> 1. there are no obvious uses for buffer-predicate if it doesn't also
>>    work for kill-buffer
>
> If the buffer predicate affects _only_ what `kill-buffer', `bury-buffer'
> or `replace-buffer-in-windows' do, then this should be reflected in the
> name of the parameter 

OK

> and `other-buffer' probably should not even care about this parameter.

Why not?

>> 2. IIUC it used to work for kill-buffer, probably because kill-buffer
>>    used to call other-buffer.
>
> I think so.  And it would have been easier to avoid the problem we
> discuss here if the parameter had a better name and/or description.

Probably.

-- 
Dave Abrahams
BoostPro Computing                  Software Development        Training
http://www.boostpro.com             Clang/LLVM/EDG Compilers  C++  Boost