From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Luc Teirlinck Newsgroups: gmane.emacs.devel Subject: Re: [drew.adams@oracle.com: Info on define-minor-mode - :init-valueor :initial-value?] Date: Thu, 28 Jul 2005 21:56:25 -0500 (CDT) Message-ID: <200507290256.j6T2uPh18315@raven.dms.auburn.edu> References: NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1122606075 26678 80.91.229.2 (29 Jul 2005 03:01:15 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 29 Jul 2005 03:01:15 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 29 05:01:14 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DyL6j-0002Nr-Jv for ged-emacs-devel@m.gmane.org; Fri, 29 Jul 2005 05:00:21 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DyL9D-000155-4s for ged-emacs-devel@m.gmane.org; Thu, 28 Jul 2005 23:02:55 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DyL6r-0000c0-QS for emacs-devel@gnu.org; Thu, 28 Jul 2005 23:00:30 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DyL6b-0000Tj-9w for emacs-devel@gnu.org; Thu, 28 Jul 2005 23:00:14 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DyL6W-0000Sz-8j for emacs-devel@gnu.org; Thu, 28 Jul 2005 23:00:08 -0400 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DyLEy-00040i-Ux for emacs-devel@gnu.org; Thu, 28 Jul 2005 23:08:53 -0400 Original-Received: from raven.dms.auburn.edu (raven.dms.auburn.edu [131.204.53.29]) by manatee.dms.auburn.edu (8.12.10/8.12.10) with ESMTP id j6T2v9CK024228; Thu, 28 Jul 2005 21:57:09 -0500 (CDT) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.7p1+Sun/8.11.7) id j6T2uPh18315; Thu, 28 Jul 2005 21:56:25 -0500 (CDT) X-Authentication-Warning: raven.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: drew.adams@oracle.com 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 Xref: news.gmane.org gmane.emacs.devel:41293 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:41293 Drew Adams wrote: WRT the guideline of "loading must not change anything" - I agree, but I think that turning on a minor mode is usually relatively benign, because it can be turned off easily. Users loading a library that defines a minor mode will not be shocked if the mode is turned on by default, if the logical initial value to use is something other than nil. Otherwise, if we're going to be rigid about this guideline (perhaps there are good reasons to do that, even in this case), Emacs is completely inconsistent in how well it follows these guidelines. The _default_ :initialize function is custom-initialize-reset. That means that whenever a file containing a defcustom with a :set function is loaded, that :set function is called _even_ if the user customized the variable outside Custom, possibly in an attempt to avoid the :set function. In vain. The `custom-initialize-reset' bully will force the :set function on the user anyway. This has repeatedly caused me (and other people) problems in practice. We have systematically dealt with these problems on a one by one basis by overriding the default with an explicit, more polite, :initialize function for those defcustoms for which problems were reported. But additional problems keep popping up on a regular basis (see the `fringe-indicators' thread). The problems are often not that easy to trace down to custom-initialize-reset, because they occur when a file is loaded and for instance Custom loads tons of files behind the user's back. The reason for picking `custom-initialize-reset' as the default are autoloaded defcustoms with a :set function. But I believe that there _must_ be other ways to deal with such defcustoms than the bullyish custom-initialize-reset. A second :initialize function is custom-initialize-set. That one only calls the :set function if the variable is still unbound. This means that, if nothing else, the user can avoid the :set function by setting the variable outside Custom in his .emacs file. (For preloaded defcustoms, the user can undo the effects of the :set function in his .emacs file.) For non-preloaded defcustoms, even setting the variable to its standard value avoids calling the :set function, which could be useful, if you do not want the :set function to set a timer, hide some text, make some text read-only or perform all kind of other "courtesies" that :set functions like to do. On the other hand, the only :set function considered safe for minor modes is custom-initialize-default, which _never_ calls the :set function on initialization. This is completely inconsistent as the minor-mode :set functions are usually benign compared to some other :set functions that are out there. (See `fringe-indicators' for a really bad example of :set function abuse.) Actually, the standard :set function of define-minor-mode is one of the few classes of functions for which even custom-initialize-reset would be safe. So on the one hand I have trouble convincing people that we should try to get rid (after the release) of custom-initialize-reset by finding another solution for the autoload problem and on the other hand, I have trouble convincing Stefan that the _much_ more benign custom-initialize-set can be safe for minor modes that are natural to enable by default. Sincerely, Luc.