From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alp Aker Newsgroups: gmane.emacs.bugs Subject: bug#12081: 24.1; buffer-predicate often not called Date: Sun, 29 Jul 2012 13:31:18 -0400 Message-ID: References: <5015411C.30803@gmx.at> <50156DFA.8030104@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: dough.gmane.org 1343583120 4814 80.91.229.3 (29 Jul 2012 17:32:00 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 29 Jul 2012 17:32:00 +0000 (UTC) Cc: Dave Abrahams , 12081@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Jul 29 19:31:59 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1SvXLS-0003JI-OV for geb-bug-gnu-emacs@m.gmane.org; Sun, 29 Jul 2012 19:31:58 +0200 Original-Received: from localhost ([::1]:40340 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SvXLS-0000m3-2S for geb-bug-gnu-emacs@m.gmane.org; Sun, 29 Jul 2012 13:31:58 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:41297) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SvXLO-0000ly-UQ for bug-gnu-emacs@gnu.org; Sun, 29 Jul 2012 13:31:56 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SvXLN-0003eO-Jj for bug-gnu-emacs@gnu.org; Sun, 29 Jul 2012 13:31:54 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:39458) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SvXLN-0003eK-Dv for bug-gnu-emacs@gnu.org; Sun, 29 Jul 2012 13:31:53 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1SvXSH-0000eT-Vq for bug-gnu-emacs@gnu.org; Sun, 29 Jul 2012 13:39:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alp Aker Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 29 Jul 2012 17:39:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12081 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 12081-submit@debbugs.gnu.org id=B12081.13435835112467 (code B ref 12081); Sun, 29 Jul 2012 17:39:01 +0000 Original-Received: (at 12081) by debbugs.gnu.org; 29 Jul 2012 17:38:31 +0000 Original-Received: from localhost ([127.0.0.1]:49004 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SvXRm-0000dj-J9 for submit@debbugs.gnu.org; Sun, 29 Jul 2012 13:38:31 -0400 Original-Received: from mail-yx0-f172.google.com ([209.85.213.172]:34613) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SvXRk-0000db-Ak for 12081@debbugs.gnu.org; Sun, 29 Jul 2012 13:38:29 -0400 Original-Received: by yenq13 with SMTP id q13so4145469yen.3 for <12081@debbugs.gnu.org>; Sun, 29 Jul 2012 10:31:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LfgFBnSPdPBzw4GOHJxeWX59mHiSAgp0VJ3GK5KCzRc=; b=P2XtHdHEMUZeHtKxCuUF6PnlBU+9zxjTsZBC2ykkQ7HECdegnCqacbKgUkL+7gvgyZ r1nE7lGug/VDsEztrhMUuMdIdaeCdN1tub8icMWvwh9eKtKCUDPhPvRWn7kKFpAtVBkP wRcSOsTQfr5B3RKjzyJjB1O71X2Vs4FhG7EE17DI3h64QNySSWOLY03cBLIum7LkMofd OEg3x/RxZCGISFRxzarQTwIDvRZgiQ9oJn+RyJwTXnM5DS2D7mTi5/DCcGZyO122qG0D iGDzreRRnkKNzxvhqByGLpW/sOwR4E2Im48z4E6wRHiiMroeMN4AcmVjhwLBEBfE444Y 1hfg== Original-Received: by 10.42.70.136 with SMTP id f8mr5307349icj.28.1343583078695; Sun, 29 Jul 2012 10:31:18 -0700 (PDT) Original-Received: by 10.64.142.70 with HTTP; Sun, 29 Jul 2012 10:31:18 -0700 (PDT) In-Reply-To: <50156DFA.8030104@gmx.at> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:62573 Archived-At: On Sun, Jul 29, 2012 at 1:08 PM, martin rudalics 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? 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))