From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: Changed outside --> set, in Customize UI Date: Fri, 11 Feb 2005 13:15:08 -0800 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1108156821 22717 80.91.229.2 (11 Feb 2005 21:20:21 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 11 Feb 2005 21:20:21 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 11 22:20:21 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1CziCy-0000qC-LM for ged-emacs-devel@m.gmane.org; Fri, 11 Feb 2005 22:20:14 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CziRy-000785-VS for ged-emacs-devel@m.gmane.org; Fri, 11 Feb 2005 16:35:43 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1CziRE-0006zm-O0 for emacs-devel@gnu.org; Fri, 11 Feb 2005 16:34:56 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1CziR8-0006wE-SY for emacs-devel@gnu.org; Fri, 11 Feb 2005 16:34:53 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CziR8-0006wA-PC for emacs-devel@gnu.org; Fri, 11 Feb 2005 16:34:50 -0500 Original-Received: from [148.87.122.33] (helo=rgminet04.oracle.com) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1CziD9-0000SN-MX; Fri, 11 Feb 2005 16:20:24 -0500 Original-Received: from rgminet04.oracle.com (localhost [127.0.0.1]) by rgminet04.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j1BLKM5U010152; Fri, 11 Feb 2005 16:20:22 -0500 Original-Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.191.50]) by rgminet04.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j1BLFB1u005195; Fri, 11 Feb 2005 16:16:55 -0500 Original-Received: from rgmsgw301.us.oracle.com (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j1BLFAEP005110; Fri, 11 Feb 2005 14:15:10 -0700 Original-Received: from dradamslap (dhcp-amer-csvpn-gw1-141-144-66-154.vpn.oracle.com [141.144.66.154]) by rgmsgw301.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with SMTP id j1BLF9Qj005092 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 11 Feb 2005 14:15:09 -0700 Original-To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org X-MailScanner-To: ged-emacs-devel@m.gmane.org Xref: main.gmane.org gmane.emacs.devel:33267 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:33267 I [RMS] said: To avoid confusion. In general, it is a good idea to separate the values that users set from the values that programs set. You [Drew] responded with a misunderstanding: Pick a level of unity for the "Set" (vs "changed-outside") club: 1. Set inside Customize. 2. #1 + `set-variable' used interactively. 3. #2 + any command called interactively that has as purpose to change the value. 4. #3 + any interactive command, used interactively or not. 5. #4 + any function or sexpr executed interactively (`M-:'). 6. #5 + any function or sexpr called by any function or sexpr in #5. 7. #6 + explicitly loading any library (interactively). 8. #7 + loading any library in your custom file (.emacs). 9. #8 + loading any library, even indirectly. You're trying to distinguish cases based on MECHANISMS used to set the variable. That's not the kind of distinction we are making. We are not talking about how it's done. The distinction here is who decides to set this particular variable. Does a certain Lisp program decide, or does the user decide. Yes. I argued that _none_ of the above mechanisms is an adequate indicator of "who decides to set this particular variable." We agree, I think, that _no_ mechanism is ultimately adequate to that task. The question of who is deciding a particular change can only truly be answered by the user. But we have no choice: _If_ we try to determine _by code_ who is doing the deciding, then we need some objective criterion (we don't want to ask the user, about each change that is made, "Did you intend that?"). IOW, we must look at how a change is made _if_ we wish to maintain an outside/inside distinction - we must examine the setting mechanisms. And the current scheme does indeed make the determination based on mechanism (clicking Set inside C. vs everything else). The question you posed does not require an answer. This is the two-part question I posed: "Is there is a good inside/outside boundary to choose? Which kinds of changes should we allow inside the "Set" club?" The placement (and the need) of this boundary has been the question from the beginning. It requires an answer _if_ people are arguing for maintaining an inside/outside distinction: How is the boundary to be defined? My answers to the two-part question are (1) "No, there is no good boundary" and (2) "All changes should be considered to 'set' options". I argued that none of the mechanisms I listed is adequate to the task: All user-option changes, no matter how they are made, should be admitted to the Customize club. The inside/outside distinction is not a useful one to maintain. If my list of "mechanisms" is not complete or is off the mark, if there is an adequate criterion to distinguish inside changes from outside changes (whether "mechanism" or not), let's hear it. I said in an earlier message, and you seemingly agreed: The idea behind limiting Customize admission to only interactive functions I think hints at the proper criterion, but it does not hit it square on. The idea of user Helen "setting" an option really comes down to this: user _intention_. That is not a criterion we can test by program, but it is the only reasonable criterion, IMO. I agree; I think that's exactly what it means to me. Users set variables by running programs. The difference is that in one case the intention to set variable X is embodied in the program code; in the other, the progranm could set any variable, but the user chooses to set X. You seem to agree in general, but you also seem to suggest that the particular program code could be examined to determine intention - if it offers the user a choice, then presumably the user is in charge; if it does not, then the _program is deciding_. Is that what you mean? If so, then I disagree. Even a program that offers no choice can be run or not, according to user choice. That particular mechanistic criterion (program offers a choice or not) is no better than interactive vs non-interactive. Again, user intention "is not a criterion we can test by program." I proposed that we make no inside/outside distinction, that we regard all changes to user options as "setting" them. What to do, then, about programs and libraries that set options? I pointed out that some are _designed_ to set options (and when a user runs them, the user is choosing to set those options), and some (multi-user libraries, in particular) should not set options (if they do so now, they must be corrected). I argued that the only exception to considering all option changes as "setting" the options is the startup sequence: This difference in library kind (purpose) can be reflected in the treatment by Customize. It is normal for .emacs and personal libraries loaded at startup to set user options. Those option values should not then be considered "changed outside" or even "set" in Customize. They should be considered as the normal, usual, baseline values for that user. That is, they should constitute the "unchanged" zeros of the Customize world. This "personal option calibration" (using startup values as baseline values) is simply a convenience, to let users distinguish any changes that are made after their persistent preferences are loaded (where "persistent preferences" includes values set by libraries loaded at startup). It has nothing to do with the changed inside/outside distinction. In my proposal, there is no inside/outside distinction - the only states are `saved', `standard', and `set'. `Standard' is defined by defcustom; `saved' (or `unchanged') is defined by whatever values are established during startup; `set' results from _any_ option change made after startup (except change to `standard'). All code that changes user options "sets" them, but if code is run during startup we would mark the values as "unchanged", as a convenience. The _same_ code can thus result in Customize considering the library's settings as "unchanged" (if run during startup) or "set" (if run after startup). In no case would any option be marked in Customize as "changed outside". It is thus not the character of the code that makes a difference, but what the user does with it: If a "library" of user settings (setq this and that) is loaded during startup, the user intends those settings as part of his baseline setup ("unchanged", aka "saved"). If the user loads such a library after startup, the user intends its settings to be regarded as changes ("set"). This convenience does mix together, under the category `saved' (or `unchanged') 1) values that are saved by writing them in the custom file with custom-set* with 2) values that are established during startup by loaded libraries. All such baseline values are persistent: restarting Emacs will reestablish them as the user's normal settings. But their origin is different. I think that combining (1) and (2) is a useful convenience - it is better to see "unchanged" in Customize next to a value that is set by some library during startup than it is to see "set" next to it. This could be debated: some people might prefer to distinguish (1) from (2). The idea is to let users see changes they make in their .emacs and other personal libraries show up as their "unchanged" ("saved") personal settings. We will of course need to fix the bugs we've discussed, and get rid of any inappropriate setting of user options in multi-user libraries (e.g. standard libraries), so that this convenience actually reflects _persistent personal preferences_ and not rogue option changes made by misbehaving libraries. [Luc] Referring to something set in .emacs as "Set for the current" session would be very confusing because things set in .emacs outside and inside the `custom-set-variables' form are set in the same session. [RMS] I agree. Perhaps "set by .emacs" should be distinguished as a state. We agree not to use "set" for startup settings. I proposed to use "unchanged" (aka `saved'). I'm not convinced that it is useful to distinguish custom-set* settings from .emacs settings in this regard, but I'm open to being convinced that "set by .emacs" (startup) should be distinguished as a separate state. Reasons? Things set "in .emacs outside and inside the `custom-set-variables' form are set in the same session"; and they are both set during startup; and they are both persistent ("saved"), although they are not saved in the same place or reestablished in the same way. I'm not sure whether we disagree, since you apparently agree with the "new tack" points (except #10), which in fact reflect what I've written above. And what do others think?