From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: display-buffer-alist simplifications Date: Fri, 05 Aug 2011 15:22:15 -0400 Message-ID: References: <87mxgem09k.fsf@stupidchicken.com> <4E22AE2B.5040806@gmx.at> <4E248102.6080904@gmx.at> <4E380918.3060806@gmx.at> <4E397611.5020603@gmx.at> <87oc037qwj.fsf@mail.jurta.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1312600307 3890 80.91.229.12 (6 Aug 2011 03:11:47 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 6 Aug 2011 03:11:47 +0000 (UTC) Cc: martin rudalics , Chong Yidong , emacs-devel@gnu.org To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 06 05:11:41 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 1QpXIa-0008Uc-Hw for ged-emacs-devel@m.gmane.org; Sat, 06 Aug 2011 05:11:40 +0200 Original-Received: from localhost ([::1]:48227 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QpXIZ-00042U-VY for ged-emacs-devel@m.gmane.org; Fri, 05 Aug 2011 23:11:39 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:38070) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QpXIV-0003uh-BW for emacs-devel@gnu.org; Fri, 05 Aug 2011 23:11:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QpXIT-0000yo-09 for emacs-devel@gnu.org; Fri, 05 Aug 2011 23:11:34 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.183]:10298 helo=ironport2-out.pppoe.ca) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QpXIS-0000xs-Eu for emacs-devel@gnu.org; Fri, 05 Aug 2011 23:11:32 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAK6wPE5FxKeo/2dsb2JhbABCp2p4gUABAQQBViMFCws0EhQYDSSIAL8VhkYEn1OEMQ X-IronPort-AV: E=Sophos;i="4.67,327,1309752000"; d="scan'208";a="129254189" Original-Received: from 69-196-167-168.dsl.teksavvy.com (HELO ceviche.home) ([69.196.167.168]) by ironport2-out.pppoe.ca with ESMTP/TLS/ADH-AES256-SHA; 05 Aug 2011 23:11:19 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 0952D663BB; Fri, 5 Aug 2011 15:22:16 -0400 (EDT) In-Reply-To: <87oc037qwj.fsf@mail.jurta.org> (Juri Linkov's message of "Fri, 05 Aug 2011 19:45:05 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.183 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:142917 Archived-At: >> What problems do you guys (fore)see with such a setup? > Let's see how such a setup serves some specific test-cases: > 1. The user should be able to specify whether to display the buffer > in the same window or in another window and which window > to select after displaying the buffer in another window. Hmm... please use your words carefully. I recommend you use "user" for the guy who sets up buffer-display-alist (via Customize) and "caller" for the guys who write the code that calls display-buffer. > Currently these differences are encoded in function names: > `switch-to-buffer' - display buffer in the selected window > `pop-to-buffer' - display buffer and select its window > `display-buffer' - display buffer, but don't select its window pop-to-buffer just calls display-buffer and then selects the chosen window, so it's can be ignored. switch-to-buffer would either use set-window-buffer (and circumvent the whole display-buffer business) or call pop-to-buffer with a '(display-buffer-same-window) RULE argument, which can then be overridden by buffer-display-alist. > and they are used quite inconsistently in applications. And there's not much we can do about it, other than try and provide good new functionality to encourage coders to do it better in the future. > For instance, to display the "*vc-diff*" buffer, > `vc-diff-internal' calls (pop-to-buffer "*vc-diff*"), > but `vc-annotate-show-diff-revision-at-line-internal' > calls (switch-to-buffer "*vc-diff*"). > How the user can override these application defaults? All those cases can be overridden by buffer-display-alist. > To display the "*vc-diff*" buffer in the selected window > (like `switch-to-buffer'): > (setq display-buffer-alist '( > ("*vc-diff*" display-buffer-same-window))) > To display the "*vc-diff*" buffer and not select its window: > (setq display-buffer-alist '( > ("*vc-diff*" display-buffer-other-window))) Ah, so your point is that the user should also have control over the window selection? I think this is outside the scope of the current design (changing the selected window returned by switch-to-buffer, pop-to-buffer, and display-buffer would break too much code). So the same-window vs other-window controls where the buffer is displayed but not which window ends up selected in the end. > 2. How the user can override the global defaults? > For instance, I want to display the *Help* buffer in the selected window. > But when it's already displayed in another window, then prefer reusing > another window (because otherwise two windows will be displayed with the > same buffer). And not reuse a window on another frame. > Should I write a new function and use it like: > (setq display-buffer-alist '( > ("*Help*" display-buffer-other-window-same-frame-or-same-window))) Yes, I think that would be the answer. > Or provide additional arguments to the predefined functions like: > (setq display-buffer-alist '( > ("*Help*" display-buffer-same-window reuse-other-window-same-frame))) > Or > (setq display-buffer-alist '( > ("*Help*" display-buffer-same-window (reuse-window . same-frame)))) We could provide a fancy-display.el package defining a magical display-buffer-according-to-specifiers which would interpret its parameters in a similar way to what is now done in Martin's buffer-display-alist. > 3. How applications can override the global default? > For instance, what to do to fit the command `info-other-window': > (defun info-other-window (&optional file-or-node) > "Like `info' but show the Info buffer in another window." > (interactive (if current-prefix-arg > (list (read-file-name "Info file name: " nil nil t)))) > (let (same-window-buffer-names same-window-regexps (pop-up-windows t)) > (info file-or-node))) > into the new setup? This question is orthogonal to the current debate about how to streamline buffer-display-alist, I think. But I think the answer would be to provide an `info-internal' function which takes a DISPLAY-RULE param and then rewrite `info' and `info-other-window' in terms of that new function. I know this won't satisfy everyone, but let-binding as is done above has too many problems of its own. Maybe we could have a new display-buffer-default-rule variable (not a user option) such that display-buffer uses this variable when its RULE arg is nil, so info-other-window could do (let ((display-buffer-default-rule '(display-buffer-other-window))) (info ...)) A related issue: I tend to dislike the *-other-(frame|window) commands and would rather have C-x 4 and C-x 5 as prefix commands that modify the way the subsequent command works. Not sure how best to get this behavior. Stefan