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

Previous Next

Full log

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

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

On Mon, Jul 30, 2012 at 5:13 AM, martin rudalics <rudalics <at> gmx.at> wrote:
>
> What's the reason for doing
>
>> +      ;; If we reach this, then either: (1) we have a
>> +      ;; candidate buffer that was skipped because it was already visible
>> on
>> +      ;; the frame, in which case we switch to it now, or (2) no
>> candidate
>> +      ;; was found, in which case we switch to *scratch*.
>> +      (if visible
>> +          (setq new-buffer visible)
>> +        (setq new-buffer (get-buffer-create "*scratch*")))
>> +      (set-window-buffer-start-and-point window new-buffer))
>
> IIUC these changes are not related to the issue we're discussing here.

Adding a buffer predicate test creates a new edge case, which the
above code is intended to handle.

With the existing code, it's guaranteed that either (1) we switch to a
new buffer while scanning the next buffers or the prev buffers, or (2)
we finish those scans with `visible' set to a buffer we can switch to.
 By adding a buffer predicate test to the loops, we break that
guarantee; it becomes possible to finish the scan without switching to
a new buffer and without setting `visible' to a candidate new buffer.
This would break the function unless we provide for that case.

The question then becomes, how to deal with such a case (when the scan
of prev and next buffers does not switch to a new buffer and does not
set `visible').  One obvious option is:  Do nothing, and adjust the
rest of the function to accomodate that possibility.  Another is to
choose *scratch* as the fallback value for `new-buffer', when no other
buffer passes all the tests.  The latter seemed to me to be
preferable, as it makes replace-buffer-in-windows and
replace_buffer_in_windows_safely have similar fallback behavior, and
agrees with the fallback behavior of other-buffer as well.

Previous Next

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