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

Previous Next

Full log

Message #53 received at 12081 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#12081: 24.1; buffer-predicate often not called
Date: Mon, 30 Jul 2012 16:13:26 -0400

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

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

That's because the title is wrong; It should say "Associate buffers with
the last workgroup in which they appeared."  It is a patch to
workgroups.el, which you need to understand to understand the use-case.
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.

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

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

2. IIUC it used to work for kill-buffer, probably because kill-buffer
   used to call other-buffer. 

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

Then I think that should be considered a (design) bug.

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