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

[martin rudalics]

>> This doesn't explain why showing the buffer visiting /tmp/xx is bad
>> here.
>
> <sigh>
>
> It's only bad because the documentation led me to believe that I could
> control what would be shown after kill-buffer by using buffer-predicate.
> This is a *manufactured* test case, because my real use case is a lot
> more complicated to set up.  But I gave references to the actual case if
> you really care about the motivation.

The reference you gave is entitled "Associate buffers with the last
frame in which they appeared" and I didn't see how the current behavior
which "associates windows with the last buffer they showed" would
contradict it.  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.

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

>> It has been used in `replace-buffer-in-windows' because there was no
>> better alternative.  And it might have been a good idea to not call
>> this parameter "buffer-predicate" in the first place but something
>> more indicative.
>
> Indicative of what?

Of its intended use or impact.

>> Also the manual text
>>
>>> `buffer-predicate'
>>>      The buffer-predicate function for this frame.  The function
>>>      `other-buffer' uses this predicate (from the selected frame) to
>>>      decide which buffers it should consider, if the predicate is not
>>>      `nil'.  It calls the predicate with one argument, a buffer, once
>>>      for each buffer; if the predicate returns a non-`nil' value, it
>>>      considers that buffer.
>> is misleading:
>
>> Neither `other-buffer' nor `replace-buffer-in-windows' necessarily
>> care about which frame is selected when they get called.  When killing
>> a buffer `replace-buffer-in-windows' obviously has to act on all
>> windows on all frames.
>
> IMO this means the result of (selected-frame) will be temporarily set,
> during the call to buffer-predicate, for each frame that needs to be
> changed, and buffer-predicate will be called for each such frame.  Those
> are the only semantics that make sense as long as buffer-predicate takes
> one argument.

`other-buffer' does not select a frame when calling buffer-predicate.

martin