From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: Changed outside --> set, in Customize UI Date: Mon, 07 Feb 2005 15:51:44 -0500 Message-ID: References: Reply-To: rms@gnu.org NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1107811701 8837 80.91.229.2 (7 Feb 2005 21:28:21 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 7 Feb 2005 21:28:21 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 07 22:28:20 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1CyGPA-0003Tc-0Q for ged-emacs-devel@m.gmane.org; Mon, 07 Feb 2005 22:27:10 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CyGdM-0003FV-Bx for ged-emacs-devel@m.gmane.org; Mon, 07 Feb 2005 16:41:28 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1CyGPi-0004ra-8O for emacs-devel@gnu.org; Mon, 07 Feb 2005 16:27:22 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1CyGPc-0004pm-01 for emacs-devel@gnu.org; Mon, 07 Feb 2005 16:27:19 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CyGPa-0004YK-R0 for emacs-devel@gnu.org; Mon, 07 Feb 2005 16:27:15 -0500 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CyFuW-0001II-CP for emacs-devel@gnu.org; Mon, 07 Feb 2005 15:55:08 -0500 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.34) id 1CyFrE-0006kK-Rb; Mon, 07 Feb 2005 15:51:44 -0500 Original-To: "Drew Adams" In-reply-to: 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:33054 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:33054 Your summary is very useful, but there are some points I don't follow or disagree with. One problem mentioned is that trying to save a "changed-outside" option might not "work": some library you load might change the saved value to something different after you restart. Well, _setting_ an option in Customize and then saving it might not work either - for exactly the same reason. I don't understand the argument there. What is the secons scenario? When changing a defcustomed variable from a function, that function should be interactively called by the user Why? To avoid confusion. In general, it is a good idea to separate the values that users set from the values that programs set. 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. A user option is a user option, and it should be totally under _user_ control. Proper functioning of a user hook, for instance, should not depend on any properties of the hook value, such as additional hook functions, that the user does not control or is not aware of. If that means that we have to split lots of user hooks in two (user; system) or otherwise bend over backward to avoid stepping on user settings, then so be it - we'll just have to bite the bullet. That would be a big price to pay. Even if the other alternative is imperfect, it may still be better. It would be useful to separate these two issues even if the problems raised did not exist already and were not, therefore, unrelated to the proposed UI change. Maybe-- but we shouldn't change any of these things now, so maybe we can just as well consider them both together as part of a redesign of the Custom user interface.