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, 17 Jul 2011 11:40:59 +0200 Message-ID: <4E22AE2B.5040806@gmx.at> References: <87mxgem09k.fsf@stupidchicken.com> 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 1310895697 18295 80.91.229.12 (17 Jul 2011 09:41:37 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 17 Jul 2011 09:41:37 +0000 (UTC) Cc: emacs-devel@gnu.org To: Chong Yidong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 17 11:41:31 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 1QiNqq-0003vV-JA for ged-emacs-devel@m.gmane.org; Sun, 17 Jul 2011 11:41:28 +0200 Original-Received: from localhost ([::1]:42372 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QiNqp-0004lS-GT for ged-emacs-devel@m.gmane.org; Sun, 17 Jul 2011 05:41:27 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:47585) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QiNqV-0004kq-S6 for emacs-devel@gnu.org; Sun, 17 Jul 2011 05:41:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QiNqU-0005TP-8f for emacs-devel@gnu.org; Sun, 17 Jul 2011 05:41:07 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.23]:37041) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1QiNqT-0005TK-J3 for emacs-devel@gnu.org; Sun, 17 Jul 2011 05:41:06 -0400 Original-Received: (qmail invoked by alias); 17 Jul 2011 09:41:04 -0000 Original-Received: from 62-47-46-64.adsl.highway.telekom.at (EHLO [62.47.46.64]) [62.47.46.64] by mail.gmx.net (mp015) with SMTP; 17 Jul 2011 11:41:04 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/k+mxvz4/kasXQNTcqwOjfpJj93eyqXQQWvcgiNn RuXSfhv7vh/n8R User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: <87mxgem09k.fsf@stupidchicken.com> 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:142065 Archived-At: > - Instead of allowing the car of each `display-buffer-alist' element to > be a _list_ of matchers, let it just be a matcher. This is > semantically cleaner, and more consistent with other facilities in > Emacs, e.g. font-lock-keywords. Any caller desiring multiple > matching conditions can just add multiple alist elements. I currently produce these via `display-buffer-alist-set'. But Sam Steingold earlier bemoaned that > it produces a lot of separate entries like > (((name . "*acl-listener*")) > fun-with-args > (fun-with-args special-display-popup-frame #1#)) > (((name . "*scheme*")) > fun-with-args > (fun-with-args special-display-popup-frame #1#)) > (((name . "*allegro*")) > fun-with-args > (fun-with-args special-display-popup-frame #1#)) > (((name . "*cmu*")) > fun-with-args > (fun-with-args special-display-popup-frame #1#)) > > I think it would be better to group them together like I do above. and I think he's right. So I'd rather keep the list approach here (but can be easily convinced of the contrary ;-) ). > - Instead of buffer matchers that are cons cells like (name . NAME), > (regexp . REGEXP), and (label . LABEL), just use strings or symbols. > Strings are to be treated as regexps (if an exact match is desired, > the caller uses regexp-quote); symbols are treated as label matchers. Stefan earlier suggested something similar last year. I can do that easily but it somehow precludes that we add other string- or symbol-like types later (not that I can give or even think of an example). So if people agree on this, I'll do it. > - Some of the display specifiers seem to allow contradictory meanings, > e.g. > > (reuse-window same nil other) > > means to reuse the selected window, provided the window is not on the > selected frame. What does this mean? Hopefully that `display-buffer' can't find a window meeting this specification. It's obviously a static case which means it could be detected at the time the user sets the customization. > And what happens if it's > impossible for Emacs to meet the requirements of the specifier? This > is not explained in the docstring. It's not taken. Like when you specify to use the selected window if it shows the same buffer and the selected window shows another buffer. Or you want to split a window but `display-buffer' can't find one which is large enough. > - I don't like the fact that different specifiers are set up in a way > that the meaning of each specifier depends on the presence of other > specifiers. For example, in the spec list > > ((reuse-window same nil nil) (reuse-window-even-sizes . t)) > > the second element only has a meaning if the first element is > present---they are not independent. That's an incorrect deduction, probably because the doc-string is written badly. If you add (reuse-window (reuse-window-even-sizes . t)) as last element to `display-buffer-alist' it will apply to all reuse-window operations that don't override it. > It would be cleaner to use a > plist, like this: > > (reuse-window :window same :reuse-window-even-sizes t) > > where ALL the behaviors are grouped together. I haven't looked into how to present plists in the customization interface. If I find a good way to do it, I'll make that change. martin