[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: problem of define-minor-mode while bootstrapping

From: Dave Love
Subject: Re: problem of define-minor-mode while bootstrapping
Date: 02 Oct 2002 23:49:32 +0100
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Richard Stallman <address@hidden> 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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]