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

Previous Next

Full log

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

From: martin rudalics <rudalics <at> gmx.at>
To: Alp Aker <alptekin.aker <at> gmail.com>
Cc: 12081 <at> debbugs.gnu.org
Subject: Re: bug#12081: 24.1; buffer-predicate often not called
Date: Tue, 31 Jul 2012 10:40:15 +0200

> So, would something like the following patch be ok (after adding
> appropriate documentation changes)?

Sure.  Can you write a ChangeLog entry, one additional sentence for the
doc-strings and a more useful documentation of buffer-predicate for the
Elisp manual?

> Note that with these changes,
> there might still be some potentially odd behavior.  Here's a
> contrived example.  From Emacs -Q, evaluating the following in
> *scratch*:
>
> (progn
>   (set-frame-parameter nil 'buffer-predicate (lambda (x) nil))
>   (switch-to-buffer (get-buffer-create "foo"))
>   (switch-to-prev-buffer))
>
> will leave buffer "foo" displayed in the selected window, but the
> return value of of `switch-to-prev-buffer' will be #<buffer
> *scratch*>, because `next-buffer' was assigned during the scan of the
> previous buffers even though we did not switch to it.  Is such a
> misleading return value ok?

No.  It's an obvious bug not related to `buffer-predicate'.  It went
unnoticed so far because the return value of `switch-to-prev-buffer' is
neither documented nor used anywhere.  But in the case you describe
`switch-to-prev-buffer' should return nil just as in all other cases
resulting from

      (dolist (entry (window-prev-buffers window))
	(when (and (setq new-buffer (car entry))

when new-buffer is rejected.  I hope I fixed that now.  Please have a
look.

Thanks, martin

Previous Next

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