From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chong Yidong Newsgroups: gmane.emacs.devel Subject: Re: display-buffer-overriding-action Date: Tue, 13 Sep 2011 15:01:08 -0400 Message-ID: <8739g0jmh7.fsf@stupidchicken.com> References: <87mxgem09k.fsf@stupidchicken.com> <87wrdrc7v2.fsf@stupidchicken.com> <87sjo9hfar.fsf@stupidchicken.com> <874o0p8emk.fsf@stupidchicken.com> <87ipp4webw.fsf@stupidchicken.com> <87bouvniij.fsf@stupidchicken.com> <87aaaeikr6.fsf@stupidchicken.com> <878vpx3g4d.fsf@stupidchicken.com> <87pqj9qqhp.fsf@stupidchicken.com> <87mxealsnv.fsf_-_@stupidchicken.com> <87ipoxf9ms.fsf@stupidchicken.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1315940481 28998 80.91.229.12 (13 Sep 2011 19:01:21 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 13 Sep 2011 19:01:21 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 13 21:01:17 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1R3YEO-0004PT-6S for ged-emacs-devel@m.gmane.org; Tue, 13 Sep 2011 21:01:16 +0200 Original-Received: from localhost ([::1]:39787 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R3YEN-0003GP-FY for ged-emacs-devel@m.gmane.org; Tue, 13 Sep 2011 15:01:15 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:46311) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R3YEK-0003FU-27 for emacs-devel@gnu.org; Tue, 13 Sep 2011 15:01:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R3YEI-0007qI-Qp for emacs-devel@gnu.org; Tue, 13 Sep 2011 15:01:12 -0400 Original-Received: from vm-emlprdomr-02.its.yale.edu ([130.132.50.143]:34230) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R3YEI-0007q4-Ow for emacs-devel@gnu.org; Tue, 13 Sep 2011 15:01:10 -0400 Original-Received: from furball (dhcp-128-36-14-41.central.yale.edu [128.36.14.41]) (authenticated bits=0) by vm-emlprdomr-02.its.yale.edu (8.14.4/8.14.4) with ESMTP id p8DJ19oU023207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 13 Sep 2011 15:01:09 -0400 In-Reply-To: (Stefan Monnier's message of "Tue, 13 Sep 2011 13:59:53 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-Scanned-By: MIMEDefang 2.71 on 130.132.50.143 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 130.132.50.143 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:143988 Archived-At: Stefan Monnier writes: >> former is not a problem: C-x 5 b passes an ACTION argument to >> pop-to-buffer, which takes precedence over d-b-alist. > > No, the ACTION argument takes precedence over d-b-default-action but not > over d-b-alist. I meant d-b-default-action there. >> The display-buffer action functions aren't told what the original >> arguments to display-buffer were, so it can't know whether >> display-buffer was called for `C-x 5 b' or `C-x 4 b', or another >> command entirely. > > C-x 5 b would not do > > (display-buffer BUFFER but > (let ((d-b-overriding-action )) > (display-buffer BUFFER)) In your scheme, under what circumstances would *any* Lisp caller of display-buffer use the ACTION argument? As far as I can see, every Lisp caller falls into one of two cases: - "Generic" calls to display-buffer or pop-to-buffer, which don't intend to second guess Emacs defaults and/or user settings. - Commands like `C-x 5 b' or `info-other-window', which fall under the "explicit command" criterion and should override the defaults. Your rationale for not using the ACTION argument is to allow a third case, wherein the Lisp caller wants to specify some behavior that can be overridden by the user. I contend that Lisp callers should almost never do that: as far as possible, they should use a `bare' display-buffer or pop-to-buffer call. In that case, it's conceptually cleaner to handle the second case by letting those callers use the ACTION argument. Do you have any specific counterexamples in mind?