From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Dave Love Newsgroups: gmane.emacs.devel Subject: Re: problem of define-minor-mode while bootstrapping Date: 02 Oct 2002 23:49:32 +0100 Sender: emacs-devel-admin@gnu.org Message-ID: References: <200209191320.WAA03733@etlken.m17n.org> <200209191346.g8JDkdq07175@rum.cs.yale.edu> <200209200006.JAA04300@etlken.m17n.org> <200209201838.g8KIc8t13414@rum.cs.yale.edu> <20020921020041.GA1545@gnu.org> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1033709892 24748 127.0.0.1 (4 Oct 2002 05:38:12 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 4 Oct 2002 05:38:12 +0000 (UTC) Cc: miles@gnu.org, monnier+gnu/emacs@rum.cs.yale.edu, handa@m17n.org, emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 17xLA8-0006Qx-00 for ; Fri, 04 Oct 2002 07:38:08 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17xLvX-0008FO-00 for ; Fri, 04 Oct 2002 08:27:11 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 17xL9n-0005Y9-00; Fri, 04 Oct 2002 01:37:47 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17wsJJ-0005xe-00 for emacs-devel@gnu.org; Wed, 02 Oct 2002 18:49:41 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17wsJH-0005xH-00 for emacs-devel@gnu.org; Wed, 02 Oct 2002 18:49:40 -0400 Original-Received: from albion.dl.ac.uk ([148.79.80.39]) by monty-python.gnu.org with esmtp (Exim 4.10) id 17wsJC-0005wf-00; Wed, 02 Oct 2002 18:49:34 -0400 Original-Received: from fx by albion.dl.ac.uk with local (Exim 3.35 #1 (Debian)) id 17wsJA-0001ZJ-00; Wed, 02 Oct 2002 23:49:32 +0100 Original-To: rms@gnu.org Original-Lines: 53 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:8354 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:8354 Richard Stallman writes: > unify-8859-on-encoding-mode's value is t > > Documentation: > Non-nil if Unify-8859-On-Encoding mode is enabled. > See the command `unify-8859-on-encoding-mode' for a description of this minor-mode. > | Setting this variable directly does not take effect; > | use either M-x customize or the function `unify-8859-on-encoding-mode'. > > You can customize this variable. > > Defined in `ucs-tables'. > > No! > > I guess something is wrong in that doc string. > What part of it is wrong? What is the actual situation? I think I meant to disagree with the second part of this, which I seem to have cut: Could you show me the specific documentation? Maybe it needs to be fixed. The example above is of boiler plate for minor modes which says generally that setting the mode variable has no effect. I believe the code should be changed to reflect the documentation, not vice versa. > > Could you explain more concretely what it is that you're thinking of > > as a change in Emacs's state? > > Specifically minor modes being turned on, hooks being installed &c by > loading files, e.g. via customize-group. > > That also is so sketchy I can't really tell what scenario it > refers to. Could someone please spell out the actual scenario? I don't understand the problem with this. Those issues are well-known, and various packages have been modified to avoid them, as discussed with you. This is in (elisp)Coding Conventions anyhow: * When a package provides a modification of ordinary Emacs behavior, it is good to include a command to enable and disable the feature, Provide a command named `WHATEVER-mode' which turns the feature on or off, and make it autoload (*note Autoload::). Design the package so that simply loading it has no visible effect--that should not enable the feature.(2) Users will request the feature by invoking the command. It's possible I wrote that, but anyhow I thought everyone agreed with it, and it's easy to see you'd lose if, for instance, Viper turned on vile features when merely loaded.