unofficial mirror of emacs-devel@gnu.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

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