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 10:55:23 -0700	[thread overview]
Message-ID: <DNEMKBNJBGPAOPIJOOICCEEHDGAA.drew.adams@oracle.com> (raw)
In-Reply-To: <85iro3gt32.fsf@lola.goethe.zz>

    Customize might load a file just because a variable has been
    customized from it.

And?

    > Third, I don't see why we are stating this guideline /
    > recommendation / prescription. Users can always set the mode value
    > to nil in their init files, which, for a mode that always toggles
    > based on changes to this variable (which is the normal, recommended
    > case) will inhibit mode enabling upon load.

    Uh what?  Why should that happen?

Why shouldn't it? It works for me.

 (setq my-mode nil) ; Inhibit turning on when loaded.

By "enabling upon load" I don't mean turning the mode on systematically when
the file is loaded; I mean setting the variable value to non-nil unless it
is already defined. That's the way it works for me, at least: if the
variable is already defined, then loading the library does not set it. IOW,
I'm speaking only of the :init-value for define-minor-mode - the _default_
value if the user specifies none.

I interpreted the doc passage quoted as essentially saying that libraries
should not use ":init-value t". If I misinterpreted the passage, then what
was the real message?

    > That was the spin used previously in this doc, I believe, and I
    > think it is the correct recommendation. We should say something like
    > this (the idea, if not the wording):
    >
    >   Unless the mode automatically toggles upon changes to the mode
    >   variable, do not enable the mode upon load. Why? Because users
    >   have no way to inhibit enabling in that case.

    How do you suppose to inhibit enabling when the mode "automatically
    toggles upon changes" in this case?

By "automatically..." I mean the usual and recommended case of a minor mode
turning on and off when its variable's value changes. Inhibit default
enabling with this in your .emacs: (setq my-mode nil)

Am I missing something here?

    > That is the only case where it is important not to enable the mode
    > upon load, AFAIK. The part about modes that don't respect their
    > variable is missing in the current guideline - it speaks of
    > "painless" and "harmless", but nowhere does it explain what the pain
    > or harm is.

    Files may even get autoloaded when going through a menu.

And?

That a file gets loaded via customize of through a menu or via cosmic ray is
not the point/problem, AFAICT. The point is what that library does. If a
particular library would cause harm by enabling a minor mode by default upon
loading, then it should not do that. Otherwise, where's the beef?

The problem is not that libraries can be loaded in various under-the-covers
ways at any unforeseen time. The problem is for each library writer to
determine if enabling the mode by default upon load is appropriate. If not,
don't do that.

It would be helpful to add guidelines with examples of things that libraries
might do that would make it inappropriate to enable their mode by default
upon load. IOW, specifics please.

    > I personally think that perhaps most normal (respectful) minor modes
    > should be enabled upon load, but I wouldn't go so far as to proclaim
    > that in the doc. Enabling the mode by default upon load
    > (i.e. enabling unless the variable is nil) is "harmless", unless I'm
    > missing something. If I am missing something, then maybe that
    > something needs to be added to the doc.

    Stuff connected with autoloads and customization groups triggers at
    unusual moments.

Too vague for me. Please formulate any specific problems that should be
added to the doc, in place of a blanket "Don't do that".

  reply	other threads:[~2006-05-18 17:55 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
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 [this message]
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=DNEMKBNJBGPAOPIJOOICCEEHDGAA.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).