all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Dave Love <d.love@dl.ac.uk>
Cc: miles@gnu.org,  monnier+gnu/emacs@rum.cs.yale.edu,
	 handa@m17n.org, emacs-devel@gnu.org
Subject: Re: problem of define-minor-mode while bootstrapping
Date: 02 Oct 2002 23:49:32 +0100	[thread overview]
Message-ID: <rzqlm5gbgn7.fsf@albion.dl.ac.uk> (raw)
In-Reply-To: E17v898-000334-00@fencepost.gnu.org

Richard Stallman <rms@gnu.org> 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
  fixed.

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.

  parent reply	other threads:[~2002-10-02 22:49 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-19 13:20 problem of define-minor-mode while bootstrapping Kenichi Handa
2002-09-19 13:46 ` Stefan Monnier
2002-09-20  0:06   ` Kenichi Handa
2002-09-20 18:38     ` Stefan Monnier
2002-09-21  1:57       ` Kenichi Handa
2002-09-22 22:54         ` Stefan Monnier
2002-09-23  2:08           ` Kenichi Handa
2002-09-23 18:27             ` Stefan Monnier
2002-09-24  3:06               ` Kenichi Handa
2002-09-24 15:33                 ` Stefan Monnier
2002-09-24 23:45                   ` Kenichi Handa
2002-09-21  2:00       ` Miles Bader
2002-09-22 15:55         ` Richard Stallman
2002-09-25 22:50           ` Dave Love
2002-09-26 21:45             ` Richard Stallman
2002-09-27 14:09               ` Dave Love
2002-09-28  3:19                 ` Richard Stallman
2002-09-30  6:26                   ` Kenichi Handa
2002-10-18  7:00                     ` Richard Stallman
2002-10-18  8:38                       ` Kenichi Handa
2002-10-20  5:34                         ` Richard Stallman
2002-10-02 22:49                   ` Dave Love [this message]
2002-10-04  3:49                     ` Richard Stallman
2002-09-22 21: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

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

  git send-email \
    --in-reply-to=rzqlm5gbgn7.fsf@albion.dl.ac.uk \
    --to=d.love@dl.ac.uk \
    --cc=emacs-devel@gnu.org \
    --cc=handa@m17n.org \
    --cc=miles@gnu.org \
    --cc=monnier+gnu/emacs@rum.cs.yale.edu \
    /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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.