From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: display-buffer-alist simplifications Date: Wed, 10 Aug 2011 07:26:03 -0700 Message-ID: <90D18480FF1C477CBDE629F658650C08@us.oracle.com> References: <87mxgem09k.fsf@stupidchicken.com><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> <4E412E0B.1000002@gmx.at> <4E422EB8.1020309@gmx.at> <87zkjha6pg.fsf@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1312986391 23276 80.91.229.12 (10 Aug 2011 14:26:31 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 10 Aug 2011 14:26:31 +0000 (UTC) Cc: 'Juri Linkov' , 'Chong Yidong' , 'Stefan Monnier' , emacs-devel@gnu.org To: "=?iso-8859-2?Q?'=A9tep=E1n_Nemec'?=" , "'martin rudalics'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 10 16:26:22 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 1Qr9ji-0004Ac-GF for ged-emacs-devel@m.gmane.org; Wed, 10 Aug 2011 16:26:22 +0200 Original-Received: from localhost ([::1]:51335 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qr9jh-00038K-U1 for ged-emacs-devel@m.gmane.org; Wed, 10 Aug 2011 10:26:21 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:39418) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qr9jf-000380-2y for emacs-devel@gnu.org; Wed, 10 Aug 2011 10:26:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qr9jd-0004OR-L4 for emacs-devel@gnu.org; Wed, 10 Aug 2011 10:26:19 -0400 Original-Received: from acsinet15.oracle.com ([141.146.126.227]:44765) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qr9jd-0004OD-Ci for emacs-devel@gnu.org; Wed, 10 Aug 2011 10:26:17 -0400 Original-Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p7AEQBRQ026800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 10 Aug 2011 14:26:12 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p7AEQAdx021110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Aug 2011 14:26:10 GMT Original-Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p7AEQ4YF027457; Wed, 10 Aug 2011 09:26:04 -0500 Original-Received: from dradamslap1 (/10.159.55.111) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 10 Aug 2011 07:26:04 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87zkjha6pg.fsf@gmail.com> Thread-Index: AcxXSuUd0Y7wGVsfSJ2d/ewBMzdidQAGXLvA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4E429505.0057:SCFMA922111,ss=1,re=-4.000,fgs=0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 1) X-Received-From: 141.146.126.227 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:143109 Archived-At: > >>> I'm lost here. Do you mean that users who prefer the old > >>> `display-buffer' behavior get overridden by the > >>> application whenever it passes an argument but do get the > >>> old behavior when the application does not pass an argument? > >> > >> Yes. > > Ouch. > > Bah! Please don't let this happen. Other than being > inconsistent/confusing/crazy (I'm not quite sure what the > "old behavior" means here), wasn't the main point of the > rewrite to give power to the user? IOW, users must _always_ > be able to override what the application specified. +1, yes. But also vice versa! A user can choose to use a command or mode that overrides that user's saved option setting. Simple cases are `set-variable', `customize-set-variable', `customize-set-value', and making a temporary change in the Customize UI. Such a command is Lisp code (an "application"). That does not automatically make it anti-user or user-bullying. This is as true of code written by the same user and 3rd-party code as it is of predefined option-setting commands such as `set-variable'. It's not simply about user option vs application code. It's about how the changes are made: by user request (in one form or another) or by programmatic fiat (i.e., more or less beyond user control). It's all about respecting the user. A user can choose to run code, and that code, just like a user setting, should be able to take precedence. This is what we do generally in Emacs. We have saved user settings and code can override those settings. It is up to the particular code to respect a user's wishes and put itself at the demand (invocation) of users - e.g. in the form of a command, minor mode, etc. There is no way to determine a priori whether any given code is respectful of users in this way. Attempts to order such things strictly are misguided. Each day that goes by seems to see this discussion reshuffling the proposed override order or adding new "levels" to it. No such tower of levels will suffice if you try to rely on it to enforce things strictly. You will simply confuse the hell out of users (and maintainers!) and frustrate anyone who tries to do anything unforeseen wrt your order. Some default ordering is fine, but there should be no attempt to prevent code from overriding user settings etc. What we do with `default-frame-alist', face definitons, etc. is reasonable: users can define their default preferences, but they can also (e.g. using that bogeyman `code'') change things on the fly. In Emacs more than other places, users can write code themselves, including code that dynamically changes their own saved settings. This is Emacs 101. > users must _always_ be able to override what the application specified. sm> Don't worry about that. We were only talking about the case where the sm> user does not use buffer-display-alist. Even if a user does use that option (or any other), code should still be able to override such settings. Don't think automatically "code versus user"; think also "code invoked on demand by user". There is code and there is code. Not all code that overrides a saved user setting is doing something the user does not want.