emacs-devel
[Top][All Lists]
Advanced

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

Re: doc of defining minor modes


From: Stefan Monnier
Subject: Re: doc of defining minor modes
Date: Thu, 18 May 2006 23:21:52 -0400
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

>     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.

It may be loaded for a silly reason.  E.g. compiling a package `foo' which
gratuitously does a (require 'bar).

> 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?

The question is not whether it does harm, but whether it changes the
user-visible behavior.  An unrequested user-visible change due to some
apparently unrelated action is bad.

> 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.

This is irrelevant.  The interesting case is when the user doesn't even know
that minor mode exists.

>     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
> :init-value.

Feel free to disagree, but this has been decided after a good bit of thought
and experience.


        Stefan




reply via email to

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