From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Richard M. Stallman" Newsgroups: gmane.emacs.devel Subject: Re: [drew.adams@oracle.com: Info on define-minor-mode - :init-valueor :initial-value?] Date: Sun, 31 Jul 2005 20:45:43 -0400 Message-ID: References: <200507290256.j6T2uPh18315@raven.dms.auburn.edu> <200507310043.j6V0hDm25599@raven.dms.auburn.edu> Reply-To: rms@gnu.org NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1122858295 26621 80.91.229.2 (1 Aug 2005 01:04:55 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 1 Aug 2005 01:04:55 +0000 (UTC) Cc: drew.adams@oracle.com, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 01 03:04:52 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DzOj4-00031l-VL for ged-emacs-devel@m.gmane.org; Mon, 01 Aug 2005 03:04:19 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DzOlh-0008AC-CR for ged-emacs-devel@m.gmane.org; Sun, 31 Jul 2005 21:07:01 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DzOh4-00069K-KO for emacs-devel@gnu.org; Sun, 31 Jul 2005 21:02:14 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DzOgL-0005Xw-TA for emacs-devel@gnu.org; Sun, 31 Jul 2005 21:01:39 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DzOgJ-0005Qn-Ar for emacs-devel@gnu.org; Sun, 31 Jul 2005 21:01:27 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DzOeB-0005Ff-9t for emacs-devel@gnu.org; Sun, 31 Jul 2005 20:59:15 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.34) id 1DzOR5-0003vT-Tr; Sun, 31 Jul 2005 20:45:43 -0400 Original-To: Luc Teirlinck In-reply-to: <200507310043.j6V0hDm25599@raven.dms.auburn.edu> (message from Luc Teirlinck on Sat, 30 Jul 2005 19:43:13 -0500 (CDT)) 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: news.gmane.org gmane.emacs.devel:41389 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:41389 That seems like the right thing to me. If the user set the variable, he probably wanted to control the mode. In the text you quoted, I was talking about defcustoms with a :set function that are _not_ minor modes. I don't think this changes anything, but let's call it "behavior" rather than "mode". So what? One can't please everybody. I thought that we decided that use of Custom was optional, that people should be able to customize everything in their .emacs and completely ignore Custom, if that is what they wanted to do. That is just a goal, not an unbreakable rule. It seems irrelevant to this issue anyway. We're not talking about running Custom here. We're talking about what happens when you load a defcustom and the variable has already been set. If you try to customize things manually in your .emacs you subject yourself to Custom overriding you at random moments, without notice, when some file is loaded (for instance by Custom). It's not Custom that's doing this, it is loading the defcustom. Let's not complicate the issue unnecessarily. Prior cases that were known to give problems have been solved already in various ways, but people just keep writing new very intrusive :set functions. We just have to fix them to be less intrusive. Perhaps we could develop a list of guidelines they should follow. For instance, suppose that setting a variable only takes effect if a timer is set. People using Custom have come to expect that just setting a variable through Custom is sufficient. So you have to provide a :set function that calls the timer. Do you mean, that sets up the timer? Now somebody who wants the feature sometimes enabled and sometimes not might set a very complex value for the variable in his .emacs and then enable and disable the feature for that complex value by repeatedly setting and unsetting the (autoloadable) timer. Do you mean activating and canceling the timer? It seems like asking for trouble. But every so often the feature will be mysteriously silently enabled, when some file is silently loaded, for instance by Custom. The variable could have three states: an active timer, an inactive timer, and nil meaning no timer has been set. The set function could create the timer only if the variable is nil.