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 10:06:04 -0700 Message-ID: <0C641EFEDF8A49C993364338F34E62F9@us.oracle.com> References: 90D18480FF1C477CBDE629F658650C08@us.oracle.com <4E42B250.1030104@gmx.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1312995992 24735 80.91.229.12 (10 Aug 2011 17:06:32 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 10 Aug 2011 17:06:32 +0000 (UTC) Cc: emacs-devel@gnu.org To: "'grischka'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 10 19:06:28 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 1QrCEd-0000bE-Kv for ged-emacs-devel@m.gmane.org; Wed, 10 Aug 2011 19:06:27 +0200 Original-Received: from localhost ([::1]:33378 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QrCEd-0007gq-0I for ged-emacs-devel@m.gmane.org; Wed, 10 Aug 2011 13:06:27 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:51993) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QrCEX-0007gS-8j for emacs-devel@gnu.org; Wed, 10 Aug 2011 13:06:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QrCET-0007Vl-BW for emacs-devel@gnu.org; Wed, 10 Aug 2011 13:06:21 -0400 Original-Received: from acsinet15.oracle.com ([141.146.126.227]:38896) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QrCET-0007Vd-2B for emacs-devel@gnu.org; Wed, 10 Aug 2011 13:06:17 -0400 Original-Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p7AH6CVI009892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 10 Aug 2011 17:06:14 GMT Original-Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p7AH6AaV018232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Aug 2011 17:06:11 GMT Original-Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p7AH65Xo012645; Wed, 10 Aug 2011 12:06:05 -0500 Original-Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 10 Aug 2011 10:06:04 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4E42B250.1030104@gmx.de> Thread-Index: AcxXevl5tQQNxHvsRuybFoHYeGS5dQAAb+LA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090208.4E42BA86.0038,ss=1,re=0.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:143122 Archived-At: > > There is code and there is code. Not all code that overrides a > > saved user setting is doing something the user does not want. > > Which then would be code that overrides the user's settings in > order to do what the user wants, right? Exactly. What a user wants is not necessarily limited to the user's saved settings. Those are essentially user-specific _defaults_, nothing more. Users can sometimes want to override their own saved settings. Nothing new here. User saved settings should not automatically trump everything else, and they are not sacrosanct. What is important is giving the user the control. That includes letting users run code that dynamically changes their default, saved values. It includes code that lets them save any such changes for future use. It includes code that users can use to do these things interactively (commands), and it includes code that they might want to invoke in batch. Of course it is important to let users _know_ (doc) if some given code they might think about invoking binds or sets one of their saved settings. But if that behavior is well documented and the user chooses to invoke the code, then yes, such code should be able to unabashedly change saved user settings. That includes binding or setting a user option. It is misguided to try to make it difficult or impossible for code to do that. What is important is who controls/invokes the code, not whether the code changes user-specified default behavior. Several times in this discussion people have suggested that binding `pop-up-frames', for example, is a no-no. It is not. What is a no-no is binding such an option in code that a user might invoke without telling the user what will happen.