[Top][All Lists]

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

RE: doc of defining minor modes

From: Drew Adams
Subject: RE: doc of defining minor modes
Date: Thu, 18 May 2006 15:12:25 -0700

    > If it does not already have a value when the library is
    > loaded, then the library can set the (default) value to on
    > or off, as appropriate. If on is inappropriate for some
    > particular library for some reason, then its
    > :init-value should be nil.

    > Please provide a specific scenario of the problem you see

    Elisp packages may be loaded because the user specifically
    wants it to be loaded, but they can also be loaded for all
    kinds of other unrelated reasons.  So as a matter of principle
    the user-visible behavior of Emacs should be mostly unchanged
    by (load <foo>).

    This often means that minor modes should default to being disabled.

I don't see why. Regardless of why/when a file is loaded, it should be
loaded for some good reason. For many libraries, that reason includes using
a minor mode defined in the file. In those cases, if it causes no harm for
the mode to be enabled upon load (also the majority of cases, IMO), then why
shouldn't the library do that?

I expect that many, if not most, libraries defining minor modes will fit
this mould. According to what the doc says, however, and what I'm hearing
here, none of them should enable the mode (except the corner case you
describe below).

I've still seen no scenario describing the harm. All I've heard is that the
library might be loaded in any way at any time - so what? Loading the
library should not override a user setting (e.g. to inhibit turning the mode
on), no matter how or when the load occurs.

    Not always, tho: E.g. foo-aux-mode could default to being
    enabled without any harm if it only ever affects buffers
    in foo-mode and foo-mode can't exist without foo-aux-mode
    also existing (e.g. because they're defined in the
    same file of because foo.el requires `foo-aux').

This repeats what is said in the doc. I don't see it as the only, or even
the typical, case where it should be permissible to use a non-nil

What the doc suggests, without saying so explicitly, and likewise for the
replies I've gotten here, is that :init-value is not intended for general
use, but is reserved for the specific corner case you describe:

I don't agree that that is appropriate (unless I see a harmful scenario),
but if that is the decided policy then at the very least it should be stated
clearly (much more clearly than now) - tell users in so many words not to
use :init-value except for that specific corner case.

reply via email to

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