unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Dave Abrahams <dave@boostpro.com>
To: Alp Aker <alptekin.aker@gmail.com>
Cc: 12081@debbugs.gnu.org
Subject: bug#12081: 24.1; buffer-predicate often not called
Date: Sun, 29 Jul 2012 14:24:46 -0400	[thread overview]
Message-ID: <m2ehnuzaq9.fsf@pluto.luannocracy.com> (raw)
In-Reply-To: <CACxch4q6zMsD6og5MbEvTXYfo2DQqZSk0ToBpzyuSo5Hf=pjzQ@mail.gmail.com> (Alp Aker's message of "Sun, 29 Jul 2012 13:31:18 -0400")


on Sun Jul 29 2012, Alp Aker <alptekin.aker-AT-gmail.com> wrote:

> On Sun, Jul 29, 2012 at 1:08 PM, martin rudalics <rudalics@gmx.at> wrote:
>> I see.  But `kill-buffer' calls `replace-buffer-in-windows' which
>> doesn't call `other-buffer'.  Only if the buffer to be killed is still
>> current after that, `kill-buffer' calls `other-buffer'.  In the scenario
>> above it is not called.
>>
>> 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).
>
> 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.  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?

Which is what I meant by "this renders the buffer-predicate
not-very-useful."

Thanks for explaining all that for me, Alp, and for your suggested fix.
As for my use-case, it's all in
https://github.com/dabrahams/workgroups.el/commit/88a605d2a6ba47ea7a918ee8650441317826cddb
(Workgroups with buffer affinity).

>
> It seems like something like the following would restore the old functionality:
>
> === modified file 'lisp/window.el'
> --- lisp/window.el	2012-07-18 10:02:54 +0000
> +++ lisp/window.el	2012-07-29 16:59:18 +0000
> @@ -2679,10 +2679,12 @@
>  	 (old-buffer (window-buffer window))
>  	 ;; Save this since it's destroyed by `set-window-buffer'.
>  	 (next-buffers (window-next-buffers window))
> +         (pred (frame-parameter frame 'buffer-predicate))
>  	 entry new-buffer killed-buffers visible)
>      (when (window-dedicated-p window)
>        (error "Window %s is dedicated to buffer %s" window old-buffer))
>
> +    (unless
>      (catch 'found
>        ;; Scan WINDOW's previous buffers first, skipping entries of next
>        ;; buffers.
> @@ -2692,6 +2694,7 @@
>  		       (not (setq killed-buffers
>  				  (cons new-buffer killed-buffers))))
>  		   (not (eq new-buffer old-buffer))
> +                   (or (null pred) (funcall pred new-buffer))
>                     (or bury-or-kill
>  		       (not (memq new-buffer next-buffers))))
>  	  (if (and (not switch-to-visible-buffer)
> @@ -2713,6 +2716,7 @@
>  	(when (and (buffer-live-p buffer)
>  		   (not (eq buffer old-buffer))
>  		   (not (eq (aref (buffer-name buffer) 0) ?\s))
> +                   (or (null pred) (funcall pred buffer))
>  		   (or bury-or-kill (not (memq buffer next-buffers))))
>  	  (if (get-buffer-window buffer frame)
>  	      ;; Try to avoid showing a buffer visible in some other window.
> @@ -2731,16 +2735,22 @@
>  			 (not (setq killed-buffers
>  				    (cons buffer killed-buffers))))
>  		     (not (eq buffer old-buffer))
> +                     (or (null pred) (funcall pred buffer))
>  		     (setq entry (assq buffer (window-prev-buffers window))))
>  	    (setq new-buffer buffer)
>  	    (set-window-buffer-start-and-point
>  	     window new-buffer (nth 1 entry) (nth 2 entry))
> -	    (throw 'found t))))
> -
> -      ;; Show a buffer visible in another window.
> -      (when visible
> -	(setq new-buffer visible)
> -	(set-window-buffer-start-and-point window new-buffer)))
> +	    (throw 'found t)))))
> +
> +      ;; 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))
> +
>
>      (if bury-or-kill
>  	;; Remove `old-buffer' from WINDOW's previous and (restored list
> @@ -2773,10 +2783,12 @@
>  	 (frame (window-frame window))
>  	 (old-buffer (window-buffer window))
>  	 (next-buffers (window-next-buffers window))
> +         (pred (frame-parameter frame 'buffer-predicate))
>  	 new-buffer entry killed-buffers visible)
>      (when (window-dedicated-p window)
>        (error "Window %s is dedicated to buffer %s" window old-buffer))
>
> +    (unless
>      (catch 'found
>        ;; Scan WINDOW's next buffers first.
>        (dolist (buffer next-buffers)
> @@ -2784,6 +2796,7 @@
>  		       (not (setq killed-buffers
>  				  (cons buffer killed-buffers))))
>  		   (not (eq buffer old-buffer))
> +                   (or (null pred) (funcall pred buffer))
>  		   (setq entry (assq buffer (window-prev-buffers window))))
>  	  (setq new-buffer buffer)
>  	  (set-window-buffer-start-and-point
> @@ -2794,6 +2807,7 @@
>        (dolist (buffer (buffer-list frame))
>  	(when (and (buffer-live-p buffer) (not (eq buffer old-buffer))
>  		   (not (eq (aref (buffer-name buffer) 0) ?\s))
> +                   (or (null pred) (funcall pred buffer))
>  		   (not (assq buffer (window-prev-buffers window))))
>  	  (if (get-buffer-window buffer frame)
>  	      ;; Try to avoid showing a buffer visible in some other window.
> @@ -2808,6 +2822,7 @@
>  		   (or (buffer-live-p new-buffer)
>  		       (not (setq killed-buffers
>  				  (cons new-buffer killed-buffers))))
> +                   (or (null pred) (funcall pred new-buffer))
>  		   (not (eq new-buffer old-buffer)))
>  	  (if (and (not switch-to-visible-buffer)
>  		   (get-buffer-window new-buffer frame))
> @@ -2816,12 +2831,17 @@
>  		(setq visible new-buffer))
>  	    (set-window-buffer-start-and-point
>  	     window new-buffer (nth 1 entry) (nth 2 entry))
> -	    (throw 'found t))))
> -
> -      ;; Show a buffer visible in another window.
> -      (when visible
> -	(setq new-buffer visible)
> -	(set-window-buffer-start-and-point window new-buffer)))
> +	    (throw 'found t)))))
> +
> +      ;; 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))
> +
>
>      ;; Remove `new-buffer' from and restore WINDOW's next buffers.
>      (set-window-next-buffers window (delq new-buffer next-buffers))

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





  reply	other threads:[~2012-07-29 18:24 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-28 20:47 bug#12081: 24.1; buffer-predicate often not called Dave Abrahams
2012-07-29 13:56 ` martin rudalics
2012-07-29 15:05   ` Dave Abrahams
2012-07-29 17:08     ` martin rudalics
2012-07-29 17:31       ` Alp Aker
2012-07-29 18:24         ` Dave Abrahams [this message]
2012-07-29 21:37         ` Dave Abrahams
2012-07-29 23:30           ` Alp Aker
2012-07-29 23:53             ` Dave Abrahams
2012-07-30  9:13         ` martin rudalics
2012-07-30  9:35           ` Dave Abrahams
2012-07-30 17:42             ` martin rudalics
2012-07-30 20:13               ` Dave Abrahams
2012-07-31  8:39                 ` martin rudalics
2012-08-13 22:13                   ` Dave Abrahams
2012-08-14  9:09                     ` martin rudalics
2012-08-14 16:07                       ` Dave Abrahams
2012-07-30 16:22           ` Alp Aker
2012-07-30 16:33             ` Alp Aker
2012-07-30 17:42               ` martin rudalics
2012-07-31  6:59                 ` Alp Aker
2012-07-31  8:40                   ` martin rudalics
2012-08-31 17:15                   ` martin rudalics
2012-09-05 14:30                     ` martin rudalics
2012-07-30 17:42             ` martin rudalics

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m2ehnuzaq9.fsf@pluto.luannocracy.com \
    --to=dave@boostpro.com \
    --cc=12081@debbugs.gnu.org \
    --cc=alptekin.aker@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).