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: Mon, 08 Aug 2011 15:28:49 -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> <8762m9ytdi.fsf@mail.jurta.org> <8739hccjrv.fsf@mail.jurta.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1312831885 19996 80.91.229.12 (8 Aug 2011 19:31:25 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 8 Aug 2011 19:31:25 +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 Mon Aug 08 21:31:21 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 1QqVXj-0008Oi-DA for ged-emacs-devel@m.gmane.org; Mon, 08 Aug 2011 21:31:19 +0200 Original-Received: from localhost ([::1]:52663 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QqVVQ-000765-CS for ged-emacs-devel@m.gmane.org; Mon, 08 Aug 2011 15:28:56 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:44140) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QqVVM-00075Z-Uo for emacs-devel@gnu.org; Mon, 08 Aug 2011 15:28:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QqVVL-0000Wn-P9 for emacs-devel@gnu.org; Mon, 08 Aug 2011 15:28:52 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:26509 helo=ironport2-out.pppoe.ca) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QqVVL-0000WZ-Iz for emacs-devel@gnu.org; Mon, 08 Aug 2011 15:28:51 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAD84QE5FxKeo/2dsb2JhbABDpyZ4gUABAQQBViMFCws0EhQYDSSIAL5ThkcEn1WEMQ X-IronPort-AV: E=Sophos;i="4.67,338,1309752000"; d="scan'208";a="130107215" 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; 08 Aug 2011 15:28:49 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 742DD6610B; Mon, 8 Aug 2011 15:28:49 -0400 (EDT) In-Reply-To: <8739hccjrv.fsf@mail.jurta.org> (Juri Linkov's message of "Mon, 08 Aug 2011 12:45:36 +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.181 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:143028 Archived-At: >> You can already do that since Emacs-20 by setting special-display-regexp >> to something like >> (add-to-list 'special-display-regexps >> '("\\*Completions\\*" my-display-completions)) >> Tho I haven't seen any sample "my-display-completions" yet. > A possible explanation is that users don't like to write functions > to specify buffer-displaying behavior :) Most likely, especially functions such as the my-display-completions you described, which is pretty difficult to write. >>> I expect this eventually will turn `display-buffer-alist' into >> >>> (("\\*\\(vc-\\)?diff*" >>> display-buffer-according-to-specifiers (spec . val)) >>> ("\\*\\(compilation\\|grep\\)\\*" >>> display-buffer-according-to-specifiers (spec . val)) >>> ...) >> >>> because predefined spec values are easier to customize. >> Easier than what? > Selecting from the set of predefined values is easier than > writing a new function to customize the buffer-displaying behavior. My proposal to only use FUNCTION in the API does not mean we wouldn't provide a choice of alternatives in the Custom UI. I fully intend to have the same kind of "select behavior from a set of predefined values" as we have now. It's just that the values you choose are functions, so while the :tag may say "same frame" the value will be the `display-buffer-same-frame' function rather than a `same-frame' symbol. And in the docstring of buffer-display-alist we would include links to those predefined functions. And the args to those function would still be your usual ALISTs with symbols as keys. >>> Yes, a single variable would be enough to override the display-buffer's arg >>> (maybe a better name would be `display-buffer-specifiers'). >> In my proposal, these things are called "rule", where RULE has the form >> (FUNCTION . ARGS). > In classical logic, necessary part of "rule" is "condition". I don't care about which name is used. I didn't choose SPECIFIER because that's already used in this discussion for the same purpose but with a different representation and the whole point of this discussion is to figure out which representation to use. > So "rule" is rather such an element if `display-buffer-alist': > ("*Completions*" display-buffer-according-to-specifiers (spec . val)) > But since "condition" part is unnecessary in the call of `display-buffer', > what remains is just specifiers. My suggestion was to have display-buffer-alist be a list of (CONDITION . RULE). If you don't like those names, then please read my messages through a transcriptor. I don't think "RULE" appeared with any other meaning within this thread, so the transcription is unambiguous. > According to your earlier proposals such specifiers should be > as short as possible like: > (display-buffer buffer 'same-frame) > (display-buffer buffer 'same-window) > (display-buffer buffer 'other-window) > (display-buffer buffer 'nearby) > (display-buffer buffer 'near-minibuffer) > (display-buffer buffer 'below-selected) > (display-buffer buffer 'side-window) I don't know if I was worried about size, but right now I'm not too worried about size, no. > It will cause the callers to ask the questions like > why this can't be written simply as: > (display-buffer-reuse-window buffer) > (display-buffer-pop-up-window buffer) Easy: so display-buffer-alist may override it. Stefan