From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: display-buffer-alist simplifications Date: Tue, 09 Aug 2011 09:47:24 +0900 Message-ID: <87ipq7o1gj.fsf@uwakimon.sk.tsukuba.ac.jp> 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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1312850857 30552 80.91.229.12 (9 Aug 2011 00:47:37 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 9 Aug 2011 00:47:37 +0000 (UTC) Cc: Juri Linkov , 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 02:47:32 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 1QqaTk-0002yl-B8 for ged-emacs-devel@m.gmane.org; Tue, 09 Aug 2011 02:47:32 +0200 Original-Received: from localhost ([::1]:44282 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QqaTj-00069H-Uy for ged-emacs-devel@m.gmane.org; Mon, 08 Aug 2011 20:47:31 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:58710) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QqaTg-000690-6g for emacs-devel@gnu.org; Mon, 08 Aug 2011 20:47:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QqaTf-0006Cr-9f for emacs-devel@gnu.org; Mon, 08 Aug 2011 20:47:28 -0400 Original-Received: from mgmt1.sk.tsukuba.ac.jp ([130.158.97.223]:56644) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QqaTe-0006C9-PV for emacs-devel@gnu.org; Mon, 08 Aug 2011 20:47:27 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id 58C9C3FA070F; Tue, 9 Aug 2011 09:47:15 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 39C171A2D13; Tue, 9 Aug 2011 09:47:24 +0900 (JST) In-Reply-To: X-Mailer: VM 8.1.93a under 21.5 (beta31) "ginger" cd1f8c4e81cd XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 130.158.97.223 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:143035 Archived-At: Stefan Monnier writes: > My suggestion is to not merge them, basically. XEmacs specifiers do not have a mode locale. This means that in order to get mode-specific behavior, you must write mode hook functions that set up the various parameters per-buffer as they enter the mode. Guess what? This sucks for the mode author and is buggy for the user. I think it's one of the primary reasons only core developers ever explicitly manipulate specifiers.[1] Merging really is not that hard to understand, and it's the way people thing about things. It sounds simpler to avoid conflict between the particular implementation of merging and various people's intuitions and/or needs of special cases, but the alternative is playing whack-a- mole with the same bug reappearing every time somebody tries to copy the behavior from one context to another. This is not a drop-dead you lose argument for merging, but the conditions for behaviors being discussed do seem to nest frequently: user preference > mode > mode special buffer > user override. I think merging is very natural in this context, and should be considered at some level. Without it, the feature will not be used as often as mode authors and users would like to. Internal representation is a separate issue. You can, of course, have a fine-grained internal representation and merge at declaration time, or you can simply store the user specs and merge at use time. These have subtly different semantics for display, and rather different semantics if users want to query the spec database for some reason. Footnotes: [1] The other one is the unfortunate and buggy separation between "glyph" and "image" objects. Hi, David!