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

From: martin rudalics <[email-masked]>
Date: Mon, 30 Jul 2012 19:42:17 +0200

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