From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Lennart Borgman" Newsgroups: gmane.emacs.devel Subject: Re: Changed outside --> set, in Customize UI Date: Mon, 7 Feb 2005 17:14:08 +0100 Message-ID: <00b501c50d34$b6dc2b70$0200a8c0@sedrcw11488> References: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1107795401 16008 80.91.229.6 (7 Feb 2005 16:56:41 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 7 Feb 2005 16:56:41 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 07 17:56:34 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CyCBd-0005zL-00 for ; Mon, 07 Feb 2005 17:56:33 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CyCPn-0006G2-Lb for ged-emacs-devel@m.gmane.org; Mon, 07 Feb 2005 12:11:11 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1CyCJ1-0002z3-Tq for emacs-devel@gnu.org; Mon, 07 Feb 2005 12:04:12 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1CyCIw-0002w8-0b for emacs-devel@gnu.org; Mon, 07 Feb 2005 12:04:07 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CyCIv-0002w2-Mb for emacs-devel@gnu.org; Mon, 07 Feb 2005 12:04:05 -0500 Original-Received: from [81.228.10.107] (helo=av9-2-sn4.m-sp.skanova.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CyC3I-0001em-HH for emacs-devel@gnu.org; Mon, 07 Feb 2005 11:47:57 -0500 Original-Received: by av9-2-sn4.m-sp.skanova.net (Postfix, from userid 502) id 99F7637E8E; Mon, 7 Feb 2005 17:47:55 +0100 (CET) Original-Received: from smtp2-1-sn4.m-sp.skanova.net (smtp2-1-sn4.m-sp.skanova.net [81.228.10.183]) by av9-2-sn4.m-sp.skanova.net (Postfix) with ESMTP id 8B26A37E7A; Mon, 7 Feb 2005 17:47:55 +0100 (CET) Original-Received: from sedrcw11488 (t5o58p186.telia.com [195.67.196.186]) by smtp2-1-sn4.m-sp.skanova.net (Postfix) with SMTP id 579BD37E50; Mon, 7 Feb 2005 17:47:54 +0100 (CET) Original-To: "Drew Adams" , "Emacs-Devel" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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 Xref: main.gmane.org gmane.emacs.devel:33023 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:33023 ----- Original Message ----- From: "Drew Adams" > A user option must be under user control. However, as a general rule, > user control _includes_ the ability to use functions and libraries, > and that includes using them to set options. Yes. I believe a lot of users like customizing with other tools than the Easy Customization GUI. But I do believe that changing defcustom vars should be done with custom-set-variables (or the like) in those tools. Is that a problem? This discussion has also made me wonder if we need some clear explicit rules for this. It could look something like this: 1) defcustom vars should have a user part and a tools part (ie two variables as suggested before). Only the user part is handled in Easy Customization and saved etc. (Maybe the tools part should be shown too however.) 2) Packages that are not meant to do a saveable customization for the user changes the tools part of this double variable. 3) Those packages that want to do a saveable customization change the user part. This should be told in the description of the interactive functions that can cause such changes. 4) The user part takes precedence over the tools part. (This means that there must be a way to say "don't care about me" for the user part.) The above rules are just meant for thought now of course. > What about the use of the "changed outside" flag for those outside > changes that do represent real problems? ... > We can try to distinguish between 1) outside changes that can be seen > to represent bugs and lead to problematic behavior and 2) other > outside changes. We can then try to fix the problems. > > Until fixes are implemented, we could, as Luc suggested, display a > proper warning for the cases we can identify as problematic. I agree that it would be good, but should we not go the other way round? Until we have understood that it is not problematic should we not assume that it is? Maybe some of these problems will disappear with the suggestions Richard had for handling list defcustoms (splitting them in in a "user" and a "tool/code" part before editing them in Easy Custom).