GNU bug report logs - #12081
24.1; buffer-predicate often not called

Previous Next

Full log

View this message in rfc822 format

From: Dave Abrahams <dave <at> boostpro.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Alp Aker <alptekin.aker <at> gmail.com>, 12081 <at> debbugs.gnu.org
Subject: bug#12081: 24.1; buffer-predicate often not called
Date: Mon, 30 Jul 2012 05:35:17 -0400

on Mon Jul 30 2012, martin rudalics <rudalics-AT-gmx.at> wrote:

>>> Why is showing the buffer visiting /tmp/xx bad in your scenario?  Can
>>> you give a scenario where the present behavior really hurts you?  In
>>> that case we can try to ignore such a buffer in `switch-to-prev-buffer'.
>>
>> Well, note that it's a regression:  replace-buffer-in-windows used to
>> call other-window (via window-loop).
>
> 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.

> If you show a buffer A in a window, then show a buffer B in that
> window and subsequently kill B, the most natural thing is to show A
> again in that window.  In particular so, if B was used to display some
> temporary information.

I don't think anyone disputes that the current behavior is a good
default.  But Emacs is all about customization, and overriding defaults
is an important part of that.

>> As for how it hurts not to check buffer predicates in
>> swtich-to-prev-buffer:  Buffer predicates are supposed to provide a
>> way of exercising some control over what buffers are automatically
>> selected for display.
>
> In Dave's scenario neither of the file visiting buffers was shown
> automatically but under the user's control.

True, but I'm not sure what your point is here.  I expected to be able
to exercise some control, but couldn't.

>> But if kill-buffer doesn't respect buffer
>> predicates, then there's not much point to setting up a buffer
>> predicate at all:  why bother filtering buffers chosen for display, if
>> the filter isn't respected by one of the most common ways in which a
>> buffer is chosen for the user?
>
> `other-buffer' is used in many places for different reasons, so it's by
> no means obvious that it's about "filtering buffers chosen for
> display".

The intended use of "buffer-predicate" has no obvious (to me) connection
with the places or reasons that other-buffer is used.

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

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

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.