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: Tue, 09 Aug 2011 12:08:45 +0300 Organization: JURTA Message-ID: <87r54vq7dx.fsf@mail.jurta.org> 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 1312881148 5079 80.91.229.12 (9 Aug 2011 09:12:28 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 9 Aug 2011 09:12:28 +0000 (UTC) Cc: martin rudalics , Chong Yidong , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 09 11:12: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 1QqiMG-0002DU-24 for ged-emacs-devel@m.gmane.org; Tue, 09 Aug 2011 11:12:20 +0200 Original-Received: from localhost ([::1]:42130 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QqiMF-0002pX-6h for ged-emacs-devel@m.gmane.org; Tue, 09 Aug 2011 05:12:19 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:37908) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QqiM3-0002DX-PA for emacs-devel@gnu.org; Tue, 09 Aug 2011 05:12:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QqiLz-0007V1-St for emacs-devel@gnu.org; Tue, 09 Aug 2011 05:12:07 -0400 Original-Received: from smarty.dreamhost.com ([208.113.175.8]:33842) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QqiLz-0007UQ-M8 for emacs-devel@gnu.org; Tue, 09 Aug 2011 05:12:03 -0400 Original-Received: from ps18281.dreamhostps.com (ps18281.dreamhost.com [69.163.218.105]) by smarty.dreamhost.com (Postfix) with ESMTP id 961FC6E8094; Tue, 9 Aug 2011 02:12:01 -0700 (PDT) Original-Received: from localhost (ps18281.dreamhostps.com [69.163.218.105]) by ps18281.dreamhostps.com (Postfix) with ESMTP id 3ECBA451C11B; Tue, 9 Aug 2011 02:11:59 -0700 (PDT) In-Reply-To: (Stefan Monnier's message of "Mon, 08 Aug 2011 15:28:49 -0400") 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:143051 Archived-At: >>> 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. I agree that SPECIFIER doesn't say that it's a function call. Actually in logic, second part of the rule is called ACTION. Moreover, a function call is a typical case of ACTION. So let's be clear in the terminology from the beginning to avoid the mess and misunderstandings later: RULE ::= (CONDITION . ACTION) ACTION ::= (FUNCTION . ARGS) > My suggestion was to have display-buffer-alist be a list of > (CONDITION . RULE). Sorry, it hurts my brains to read (CONDITION . RULE). When I try to expand RULE whose first part should be CONDITION according to its classical definition, with (CONDITION . (CONDITION . (CONDITION . ...))) I'm going into infinite recursion :) >> (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. I'm worried about size, but with your design this problem could be later mitigated with something like this in `display-buffer': (let ((function (intern (format "display-buffer-%s" (car specifiers))))) (if (functionp function) (apply function args)))