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

[martin rudalics]

> 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?

This gives you little space in choosing the most suitable buffer from
that 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.

>> Maybe there's some bug in `switch-to-prev-buffer' which inhibits it to
>> behave as you want without having to customize some other option.  An
>> example might have helped to sort out such a case.
>
> Sorry, I don't know what you're talking about here.

I meant that `switch-to-prev-buffer' might have a bug independently from
whether it respects buffer-predicate or not and your example would have
helped us find such a bug.

>>> The intended use of "buffer-predicate" has no obvious (to me) connection
>>> with the places or reasons that other-buffer is used.
>> That's most unfortunate.  The documentation explicitly says that the
>> predicate affects `other-buffer'.  It nowhere says that it affects
>> `kill-buffer'.
>
> 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 and `other-buffer' probably should not even care
about this parameter.

> 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.

martin