From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: display-buffer-alist simplifications Date: Sun, 31 Jul 2011 15:49:14 +0200 Message-ID: <4E355D5A.30409@gmx.at> 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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1312120165 24669 80.91.229.12 (31 Jul 2011 13:49:25 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 31 Jul 2011 13:49:25 +0000 (UTC) Cc: Chong Yidong , emacs-devel@gnu.org To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 31 15:49: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 1QnWOP-0006wg-7O for ged-emacs-devel@m.gmane.org; Sun, 31 Jul 2011 15:49:21 +0200 Original-Received: from localhost ([::1]:34522 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QnWOO-0003tn-RR for ged-emacs-devel@m.gmane.org; Sun, 31 Jul 2011 09:49:20 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:51588) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QnWOM-0003td-I7 for emacs-devel@gnu.org; Sun, 31 Jul 2011 09:49:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QnWOL-0004rb-MY for emacs-devel@gnu.org; Sun, 31 Jul 2011 09:49:18 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.23]:57322) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1QnWOL-0004rH-Br for emacs-devel@gnu.org; Sun, 31 Jul 2011 09:49:17 -0400 Original-Received: (qmail invoked by alias); 31 Jul 2011 13:49:16 -0000 Original-Received: from 62-47-53-199.adsl.highway.telekom.at (EHLO [62.47.53.199]) [62.47.53.199] by mail.gmx.net (mp009) with SMTP; 31 Jul 2011 15:49:16 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX186gSgF67k6uQtMflwui3t5wo4dp9xCsVlZNb3Lv9 /vrmvvsVIlBVSI User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: <87mxg2fw74.fsf@mail.jurta.org> X-Y-GMX-Trusted: 0 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 213.165.64.23 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:142572 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. > 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. > But I think it should be separate from the definition of the > default behavior and should not be merged with it. If a user doesn't care about specifying an option, the default behavior will be merged in. How would you avoid that? > To help the users to customize the desired behavior we could allow > to group a set of low-level specifiers into "themes". So e.g. > for users who prefer using frames we could predefine a "frame theme" > with a set of specifiers that affect displaying buffers in frames. There are only two major groups: The pop-up-windows group and the pop-up-frames group. Reusing windows is part of both (and of the single-frame-single-window minority). > 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. > 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. martin