From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.devel Subject: Re: display-buffer-alist simplifications Date: Mon, 01 Aug 2011 11:08:18 +0300 Organization: JURTA Message-ID: <87oc09zg85.fsf@mail.jurta.org> References: <87mxgem09k.fsf@stupidchicken.com> <4E2A7EBD.7050300@gmx.at> <87livooqt6.fsf@stupidchicken.com> <4E2B158B.1080101@gmx.at> <87wrf8iyse.fsf@stupidchicken.com> <4E2BEED2.5040608@gmx.at> <8739hvu6lh.fsf@stupidchicken.com> <4E2C50E6.3020103@gmx.at> <878vrnweju.fsf@stupidchicken.com> <4E2D34D7.4040002@gmx.at> <87mxg2fw74.fsf@mail.jurta.org> <4E355D5A.30409@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1312188072 8324 80.91.229.12 (1 Aug 2011 08:41:12 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 1 Aug 2011 08:41:12 +0000 (UTC) Cc: emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 01 10:41:08 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 1Qno3f-00027w-25 for ged-emacs-devel@m.gmane.org; Mon, 01 Aug 2011 10:41:07 +0200 Original-Received: from localhost ([::1]:54326 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qno3e-0001Zq-Ij for ged-emacs-devel@m.gmane.org; Mon, 01 Aug 2011 04:41:06 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:42560) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qno3Z-0001UP-U9 for emacs-devel@gnu.org; Mon, 01 Aug 2011 04:41:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qno3Y-0004vO-7S for emacs-devel@gnu.org; Mon, 01 Aug 2011 04:41:01 -0400 Original-Received: from smarty.dreamhost.com ([208.113.175.8]:46336) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qno3X-0004vD-U3 for emacs-devel@gnu.org; Mon, 01 Aug 2011 04:41:00 -0400 Original-Received: from ps18281.dreamhostps.com (ps18281.dreamhost.com [69.163.218.105]) by smarty.dreamhost.com (Postfix) with ESMTP id 2FDC66E8059; Mon, 1 Aug 2011 01:40:59 -0700 (PDT) Original-Received: from localhost (ps18281.dreamhostps.com [69.163.218.105]) by ps18281.dreamhostps.com (Postfix) with ESMTP id 10BB4451C114; Mon, 1 Aug 2011 01:40:57 -0700 (PDT) In-Reply-To: <4E355D5A.30409@gmx.at> (martin rudalics's message of "Sun, 31 Jul 2011 15:49:14 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (x86_64-pc-linux-gnu) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 208.113.175.8 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:142621 Archived-At: >> There are three levels where the window displaying behavior can be defined: >> >> 1. default behavior with good heuristics. It can be either hard-coded > > It currently is hard-coded with the precise behavior specified by the > user's settings for the Emacs 23 options and the default fallbacks of > Emacs 23 `display-buffer'. > >> or >> defined in a defvar (or even defconst) with the current default value >> of `display-buffer-alist' (or the result of `display-buffer-alist-set'). > > The latter function in fact initializes `display-buffer-alist' from the > users old settings, the Emacs 23 default if emacs -Q is used. Very good for backward-compatibility. >> 2. function-specific behavior can be defined by the arguments >> `specifiers' and `label' of `display-buffer' and override >> the default behavior. >> >> 3. user-specific behavior can override the function-specific behavior. >> It seems `display-buffer-alist' was intended to define that. > > Not really. I assume that most `display-buffer' calls do not set the > specifiers argument. User-specific behavior can be mainly seen as what > customizing buffer display options does in Emacs 23. If and only if > users are dissatisfied with the specifiers argument they override it. I meant "user-specific behavior can override the _default_ and function-specific behavior", i.e. I forgot to mention that users can override the default behavior as well. If now the default behavior is based on the users old settings, then users new settings should override them. For instance, when old customization in .emacs sets `pop-up-frames' to t, and the user customizes `display-buffer-alist' to not create a frame, then settings from `display-buffer-alist' should override the old settings `pop-up-frames'. > If a user doesn't care about specifying an option, the default behavior > will be merged in. How would you avoid that? My concern is how users will be able to override parts of the default behavior? For instance, how users can specify a rule to override the default and to not to balance/even window sizes? I understand that using settings like (reuse-window-even-sizes . nil) and (reuse-window-even-sizes . t). >> Each group could be marked with a symbolic tag that can be used >> by the `specifiers' argument of `display-buffer', e.g.: >> >> (display-buffer "*Completions*" 'near-minibuffer) >> >> as well as in the user-customizable variable, e.g.: >> >> '(("*Completions*" below-selected) >> ("*info*" same-window)) >> >> And the value `t' could emulate the old behavior of the argument >> `not-this-window' in `display-buffer' for backward-compatibility. > > Basically, that's what macro specifiers are intended for. How easy is to add new macros like `near-minibuffer' and `below-selected'? Can users add own macros? >> As for `labels' I expect very little use of them. Maybe we should >> allow specifying the command name (i.e. the value of `this-command') >> in `display-buffer-alist', e.g.: >> >> '((("*info*" . info-other-window) same-window)) > > I consider labels as something to quickly override the behavior for a > specific function invocation until a better solution has been found. I'm sure that most authors will be lazy or forget to add labels. And how users are supposed to deal with the lack of labels? Should they send mails to the authors asking them to add labels? Honestly, I think adding labels was good intention but they are useless. For some exceptional cases where it's impossible to override the function-specific behavior based on `buffer-or-name' or `this-command', then a label could be specified as part of specifiers like `((label . "info-other-window") ...)'. Or maybe we can't remove the 3rd argument of `display-buffer' for backward-compatibility with the old version that had 3 arguments, so we should keep the 3rd argument and use it for something?