unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
Subject: RE: doc of defining minor modes
Date: Thu, 18 May 2006 15:12:25 -0700	[thread overview]
Message-ID: <DNEMKBNJBGPAOPIJOOICGEEKDGAA.drew.adams@oracle.com> (raw)
In-Reply-To: <jwvk68jnoyv.fsf-monnier+emacs@gnu.org>

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

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:
foo-aux-mode.

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	other threads:[~2006-05-18 22:12 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-18 16:38 doc of defining minor modes Drew Adams
2006-05-18 17:00 ` Andreas Schwab
2006-05-18 17:22   ` Drew Adams
2006-05-18 17:47     ` David Kastrup
2006-05-18 17:55       ` Drew Adams
2006-05-18 18:03         ` David Kastrup
2006-05-18 18:10           ` Drew Adams
2006-05-18 18:59             ` Stefan Monnier
2006-05-18 22:12               ` Drew Adams [this message]
2006-05-19  3:21                 ` Stefan Monnier
2006-05-18 20:38             ` David Kastrup
2006-05-18 22:11               ` Drew Adams
2006-05-18 22:36                 ` David Kastrup
2006-05-19  0:01                   ` Drew Adams
2006-05-19  0:25                     ` David Kastrup
2006-05-19  1:44                       ` Drew Adams
2006-05-19  6:20                         ` David Kastrup
2006-05-19 17:39                           ` Drew Adams
2006-05-19 15:59                         ` Drew Adams
2006-05-19 16:29                           ` David Kastrup
2006-05-19 17:45                             ` Drew Adams
2006-05-19 18:43                               ` Andreas Schwab
2006-05-19 16:43                           ` Stefan Monnier
2006-05-19 17:43                             ` Drew Adams
2006-05-19 17:52                               ` David Kastrup
2006-05-19 18:28                               ` Stefan Monnier
2006-05-19  1:49             ` Miles Bader
2006-05-18 17:07 ` David Kastrup
2006-05-18 17:55   ` Drew Adams
2006-05-19  2:05 ` Richard Stallman
2006-05-19 15:59   ` Drew Adams
2006-05-19 16:40     ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DNEMKBNJBGPAOPIJOOICGEEKDGAA.drew.adams@oracle.com \
    --to=drew.adams@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).