From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: John Yates Newsgroups: gmane.emacs.devel Subject: Re: display-buffer-alist simplifications Date: Tue, 9 Aug 2011 00:41:33 -0400 Message-ID: References: <87mxgem09k.fsf@stupidchicken.com> <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> <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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1312864905 6323 80.91.229.12 (9 Aug 2011 04:41:45 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 9 Aug 2011 04:41:45 +0000 (UTC) Cc: Juri Linkov , Chong Yidong , Stefan Monnier , emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 09 06:41:40 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 1Qqe8J-0001VV-Kx for ged-emacs-devel@m.gmane.org; Tue, 09 Aug 2011 06:41:39 +0200 Original-Received: from localhost ([::1]:45862 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qqe8I-0008Rf-JC for ged-emacs-devel@m.gmane.org; Tue, 09 Aug 2011 00:41:38 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:51830) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qqe8G-0008RZ-QG for emacs-devel@gnu.org; Tue, 09 Aug 2011 00:41:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qqe8F-00073z-2G for emacs-devel@gnu.org; Tue, 09 Aug 2011 00:41:36 -0400 Original-Received: from mail-iy0-f175.google.com ([209.85.210.175]:39779) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qqe8E-00073c-SJ for emacs-devel@gnu.org; Tue, 09 Aug 2011 00:41:35 -0400 Original-Received: by iyn15 with SMTP id 15so7911176iyn.6 for ; Mon, 08 Aug 2011 21:41:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=4Qq7QLmEYYZUwnEKCn59CtO3rdQ0O6WqGfKD8iQCg/g=; b=csxFW+G68yu+uWwiCtY5GNmqtVe5dmuUD1iqsPGqmOVZy6e8qnL7KqxVyb0aX988KR ssWkqbRW3/IrVlv7LNg8krVDyOtb3DLq9vdPK4Uvzf0BcyKtRfRSfUV9E8Q8H3KFwUZr jPATcWmXQzVGFfGIWD/m5j7qjD5GJYggiEW9k= Original-Received: by 10.42.162.73 with SMTP id w9mr7026758icx.417.1312864893451; Mon, 08 Aug 2011 21:41:33 -0700 (PDT) Original-Received: by 10.42.243.202 with HTTP; Mon, 8 Aug 2011 21:41:33 -0700 (PDT) In-Reply-To: <4E3FD5ED.5000206@gmx.at> X-Google-Sender-Auth: xOA93LJRKYd6oReLIl1gD9hE1V4 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.210.175 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:143040 Archived-At: On Mon, Aug 8, 2011 at 8:26 AM, martin rudalics wrote: > > With the scheme sketched above users have no chance to specify what they > want when they want to use the new design _and_ respect the application > specifiers. =A0When they set the new specifiers they would override the > application. In recent months face themes have gained significant moment. This has been facilitated by the communities' adoption of a limited number of common faces along with increased consistency in the way that supported modes use and inherit from those faces. The problem of customizing buffer display details does not seem to be nearly as far along. This is evidenced by the fact that a user specifies his display rules in terms of buffer names. That in turn requires the user to intuit a naming pattern, to hope that all mode (including those not yet explored) hew to that naming pattern, and to pray that modes defining buffers matching a given pattern all request buffer display consistently. This makes trying to achieve consistent display behavior across multiple modes feel ad hoc, analogous to attempting to tame "angry fruit salad". This is especially true when trying out a mode that one has not used before. An alternative might be to identify explicitly a limited number of buffer display protocols: - transient selection list - persistent control panel - etc Continuing with the face analogy, such buffer display protocols could easily include a notion of inheritance. Displaying a buffer would require subscribing to display a protocol. (Subscribing to a particular protocol likely would impose additional requirements / constraints.) User customization could then be associated with protocols instead of buffer names. While a big change from the current gestalt I think that such a scheme could feel significantly less ad hoc and might be easier for unsophisticated end users to master. /john