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: Thu, 11 Aug 2011 11:35:15 +0200 Message-ID: <4E43A253.9040404@gmx.at> References: <87mxgem09k.fsf@stupidchicken.com> <878vrnweju.fsf@stupidchicken.com> <4E2D34D7.4040002@gmx.at> <87r55cjvef.fsf@stupidchicken.com> <87sjpsnerd.fsf@mail.jurta.org> <4E355D2C.40709@gmx.at> <87k4axzg7j.fsf@mail.jurta.org> <87oc092gy0.fsf@stupidchicken.com> <4E380897.5000406@gmx.at> <871ux2nsrw.fsf@stupidchicken.com> <4E3AA5DA.8030403@gmx.at> <87mxfnn414.fsf@stupidchicken.com> <4E3D41F2.8060801@gmx.at> <4E3FA812.3080009@gmx.at> <87zkjkb572.fsf@mail.jurta.org> <4E3FD5ED.5000206@gmx.at> <4E412E2D.90908@gmx.at> <4E422ECA.2020207@gmx.at> 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 1313055343 2910 80.91.229.12 (11 Aug 2011 09:35:43 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 11 Aug 2011 09:35:43 +0000 (UTC) Cc: Juri Linkov , Chong Yidong , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 11 11:35:36 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 1QrRfr-0000TM-SH for ged-emacs-devel@m.gmane.org; Thu, 11 Aug 2011 11:35:36 +0200 Original-Received: from localhost ([::1]:41774 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QrRfq-0007K1-Ex for ged-emacs-devel@m.gmane.org; Thu, 11 Aug 2011 05:35:34 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:35981) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QrRfk-0007Jj-HI for emacs-devel@gnu.org; Thu, 11 Aug 2011 05:35:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QrRfg-00011c-Az for emacs-devel@gnu.org; Thu, 11 Aug 2011 05:35:28 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.22]:56655) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1QrRff-00011U-VB for emacs-devel@gnu.org; Thu, 11 Aug 2011 05:35:24 -0400 Original-Received: (qmail invoked by alias); 11 Aug 2011 09:35:20 -0000 Original-Received: from 62-47-41-54.adsl.highway.telekom.at (EHLO [62.47.41.54]) [62.47.41.54] by mail.gmx.net (mp042) with SMTP; 11 Aug 2011 11:35:20 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18GyTNlF5AG7e0SU4h3LlbYNpTUyKyGxTdCnTu7DU LXkvjl/BY/2lcJ User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: X-Y-GMX-Trusted: 0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 213.165.64.22 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:143140 Archived-At: > In the mean time I thought of 2 more: > - all the args to the display methods are in the ALIST rather than > having some in the ALIST and some bundled with the display method. > - the display method has to handle everything, there's no common/shared > postprocessing. Using a more operational reasoning I see the differences as follows: After "normalizing" specifiers (stripping buffer identifers and expanding "macro specifiers") my specifiers boil down to an alist of say methods (M) and parameters (P) like ((M ...) (P ...) (P ...) (M ...) (M ...) (P ...) (M ...) (P ...) (P ...)) This alist was produced by concatening the overriding (O), application provided (A), and non-overriding specifiers (N, where this group contains in its tail the specifiers produced by the old buffer display options) as indicated below ((M ...) (P ...) (P ...) (M ...) (M ...) (P ...) (M ...) (P ...) (P ...)) OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO AAAAAAAAAAAAAAA NNNNNNNNNNNNNNNNNNNNNNN This alist is processed by taking the first method specifier and handling _all_ following parameters just like frame alists - the first parameter value that is found is taken. If the first method fails, the next method is tried as ((M ...) (M ...) (P ...) (M ...) (P ...) (P ...)) OOOOOOO AAAAAAAAAAAAAAA NNNNNNNNNNNNNNNNNNNNNNN then the next method as ((M ...) (P ...) (M ...) (P ...) (P ...)) AAAAAAAAAAAAAAA NNNNNNNNNNNNNNNNNNNNNNN and if everything failed till here the last method as ((M ...) (P ...) (P ...)) NNNNNNNNNNNNNNNNNNNNNNN The other proposals I have seen here ask for using something I would describe as a list of alists like (((M ...) (P ...) (P ...) (P ...)) ((M ...) (P ...)) ((M ...) (P ...) (P ...))) where, if a method specifier matches, _only_ the parameters provided together with that specifier are processed. That means you process ((M ...) (P ...) (P ...) (P ...)) first, if that fails ((M ...) (P ...)) and finally ((M ...) (P ...) (P ...)) IIUC I've also seen (((M ...) (M ...) (P ...) (P ...) (P ...)) ((M ...) (M ...) (M ...) (P ...))) such that two or more methods may share the same parameters, maybe also written as ((((M ...) (M ...)) . ((P ...) (P ...) (P ...))) (((M ...) (M ...)) . ((M ...) (P ...)))) Also dismissing non-overriding specifiers and handling old buffer display options (D) has been proposed like (((M ...) (P ...) (P ...) (P ...)) OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO ((M ...) (P ...)) AAAAAAAAAAAAAAAAA ((M ...) (P ...) (P ...)) DDDDDDDDDDDDDDDDDDDDDDDDD ) where I'm still not able to see how to (1) Respect the application _and_ supply user parameters. (2) Respect the application _and_ supply parameters resulting from old user options. both of which I've called merging here. Finally, I've seen a very high priority application provided level of specifiers (H) which would appear as (((M ...) (P ...)) HHHHHHHHHHHHHHHHH ((M ...) (P ...) (P ...) (P ...)) OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO ((M ...) (P ...)) AAAAAAAAAAAAAAAAA ((M ...) (P ...) (P ...)) DDDDDDDDDDDDDDDDDDDDDDDDD ) Does this approximately describe the current state of affairs? I've deliberately dismissed things I consider sugar like whether methods represent functions or just symbols to look up functions, or whether a parameter actually is a condition enabling a method (like a window's minimum height) rather then ask for some kind of post-action (like setting a window's height). martin