From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dave Abrahams Newsgroups: gmane.emacs.bugs Subject: bug#12081: 24.1; buffer-predicate often not called Date: Sun, 29 Jul 2012 14:24:46 -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 X-Trace: dough.gmane.org 1343586365 27255 80.91.229.3 (29 Jul 2012 18:26:05 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 29 Jul 2012 18:26:05 +0000 (UTC) Cc: 12081@debbugs.gnu.org To: Alp Aker Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Jul 29 20:26:04 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 1SvYBk-0006a2-IB for geb-bug-gnu-emacs@m.gmane.org; Sun, 29 Jul 2012 20:26:00 +0200 Original-Received: from localhost ([::1]:43464 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SvYBj-0004YT-Q9 for geb-bug-gnu-emacs@m.gmane.org; Sun, 29 Jul 2012 14:25:59 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:48223) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SvYBg-0004YO-8q for bug-gnu-emacs@gnu.org; Sun, 29 Jul 2012 14:25:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SvYBd-0006kt-3R for bug-gnu-emacs@gnu.org; Sun, 29 Jul 2012 14:25:56 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:39567) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SvYBd-0006ki-0Y for bug-gnu-emacs@gnu.org; Sun, 29 Jul 2012 14:25:53 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1SvYIX-0001tA-IN for bug-gnu-emacs@gnu.org; Sun, 29 Jul 2012 14:33:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dave Abrahams Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 29 Jul 2012 18:33: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.13435867217180 (code B ref 12081); Sun, 29 Jul 2012 18:33:01 +0000 Original-Received: (at 12081) by debbugs.gnu.org; 29 Jul 2012 18:32:01 +0000 Original-Received: from localhost ([127.0.0.1]:49112 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SvYHY-0001rg-LP for submit@debbugs.gnu.org; Sun, 29 Jul 2012 14:32:01 -0400 Original-Received: from mail-vb0-f44.google.com ([209.85.212.44]:53177) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SvYHV-0001rW-MZ for 12081@debbugs.gnu.org; Sun, 29 Jul 2012 14:31:59 -0400 Original-Received: by vbbez10 with SMTP id ez10so5154078vbb.3 for <12081@debbugs.gnu.org>; Sun, 29 Jul 2012 11:24:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type:x-gm-message-state; bh=Zei1jE83Sb0D0lwLRJS76loaqHkFjrRm56jS5G/M3hs=; b=j4p0vMxZPk2u2qtIpGYRpFlsf/j2naBFBD6OW/SOawEHd59C8HW3SaF8MmYCl/84Vl 9RJdLwk70/1AxzL5PqpX02BWtEthXnSoAoIrTGbFuUxLD04Q2/wlcL/ai6Agn5KMGYxn 8BwcZvcuOYNbZs4nlF4jX/jQO5nkKUqDdwHuH+BFStQAGXIy3rvtLJpHOfQ0azXA9eMT eM2K8uSvcL1PptvzZABGzJsE+Nzf1HL3SFxSotN6FHalHI526ZQhdSJEG8veg/ip42d8 xaAzdBnBjJWBg0O+mIFr73H+tYLQ6Az41blzzMjyvE3rt0azwfQUM4hUyeU1MimN7N9b qriQ== Original-Received: by 10.220.218.133 with SMTP id hq5mr8544194vcb.60.1343586287955; Sun, 29 Jul 2012 11:24:47 -0700 (PDT) Original-Received: from pluto.luannocracy.com (207-172-223-249.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com. [207.172.223.249]) by mx.google.com with ESMTPS id k4sm7527787vdi.6.2012.07.29.11.24.46 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 29 Jul 2012 11:24:46 -0700 (PDT) Original-Received: by pluto.luannocracy.com (Postfix, from userid 501) id 668425D5FFE9; Sun, 29 Jul 2012 14:24:46 -0400 (EDT) In-Reply-To: (Alp Aker's message of "Sun, 29 Jul 2012 13:31:18 -0400") User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.1 (darwin) X-Gm-Message-State: ALoCoQlWFYc2kjZClEmLZFrc9DySQAuWbheuEAMqfiUWFM7F2uV4KWcW4kUUht9+AY951+TPQvuh 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:62579 Archived-At: on Sun Jul 29 2012, Alp Aker wrote: > 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? 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