[drew.adams@oracle.com: Info on define-minor-mode - :init-value or :initial-value?]

[drew.adams@oracle.com: Info on define-minor-mode - :init-value or :initial-value?]

[Richard M. Stallman]

Would someone please DTRT and then respond?

------- Start of forwarded message -------
From: "Drew Adams" <drew.adams@oracle.com>
To: "Emacs-Pretest-Bug" <emacs-pretest-bug@gnu.org>
Date: Tue, 26 Jul 2005 11:20:46 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Whitelist: TRUE
Subject: Info on define-minor-mode - :init-value or :initial-value?
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63

Is the keyword :init-value or :initial-value? The explanation uses the
former, but the example uses the latter.

In GNU Emacs 22.0.50.1 (i386-mingw-nt5.1.2600)
 of 2005-06-26 on NONIQPC
X server distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc
(3.3) --cflags -I../../jpeg-6b-3/include -I../../libpng-1.2.8/include -I../.
./tiff-3.6.1-2/include -I../../xpm-nox-4.2.0/include -I../../zlib-1.2.2/incl
ude'



_______________________________________________
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
------- End of forwarded message -------

Re: [drew.adams@oracle.com: Info on define-minor-mode - :init-value or :initial-value?]

[Luc Teirlinck]

Richard Stallman wrote:

   Would someone please DTRT and then respond?

For the moment, I just replaced the incorrect keyword :initial-value
in the example with :init-value.

However, probably somewhat more extensive changes are needed.  The
example (now) does:

  :init-value nil

But this is redundant, as the default :init-value is nil anyway.  So
it probably just should be deleted.

There is more.  You can not specify a non-nil :init-value, unless
either the minor mode is enabled by just setting the variable or
unless you do something extra.  That something extra is to preload the
file containing the define-minor-mode before startup.el and then using
`custom-reevaluate-setting in startup.el (for files included with the
Emacs distribution) or to call the minor mode function near the end of
the file (for files not included with the Emacs distribution).  We
could either document these requirements in the Elisp manual and the
define-minor-mode docstring or change define-minor-mode so that these
requirements are no longer necessary.  The latter requires changes
which Stefan probably would not like.  For instance it would mean that
the call to `define-minor-mode' would need to be delayed until after
all functions used by the minor mode function have been defined (but
only for define-minor-mode's with a non-nil :init-value).

Sincerely,

Luc.

Re: [drew.adams@oracle.com: Info on define-minor-mode - :init-value or :initial-value?]

[Stefan Monnier]

> There is more.  You can not specify a non-nil :init-value, unless
> either the minor mode is enabled by just setting the variable or
> unless you do something extra.

In what way is this a limitation?
I.e. if you don't use define-minor-mode, how would you do it differently?
[ I don't mean to say that "manual" code can't do it differently, but that
if it does it differently, it'll most likely break the convention that just
loading a file shouldn't make any visible changes. ]


        Stefan

RE: [drew.adams@oracle.com: Info on define-minor-mode - :init-valueor :initial-value?]

[Drew Adams]

        For the moment, I just replaced the incorrect keyword
        :initial-value in the example with :init-value.
Thanks.

    > There is more.  You can not specify a non-nil :init-value, unless
    > either the minor mode is enabled by just setting the variable or
    > unless you do something extra.

    In what way is this a limitation?
    I.e. if you don't use define-minor-mode, how would you do it
    differently?
    [ I don't mean to say that "manual" code can't do it
    differently, but that
    if it does it differently, it'll most likely break the
    convention that just
    loading a file shouldn't make any visible changes. ]

I don't know how you'll decide to handle this, but I agree with Luc that it
is confusing to set the :init-value to, say, `t' and then not see that
initial value be effective.

I did this recently, in fact. I saw the mode name appear in the mode-line
after loading the file, saw that the mode variable was indeed `t', and was
confused that the mode was not actually turned on, in spite of the mode-line
indication and the variable value. Not good, in terms of user interface.

This is not very clear to me, I admit, so ignore my comments if they are
off-base. IIUC, users creating a library with a define-minor-mode that has a
non-nil :init-value will need to do something like the following at the end
of the library (otherwise, the lighter and mode variable will indicate that
the mode is on after loading, but it is not really on):

 (if foo-mode (foo-mode 1))

If this is correct, couldn't this be made part of the define-minor-mode
macro - say, to execute this code automatically after loading the library?

If my understanding is correct, but such automatic treatment is not a good
idea, shouldn't this `(if foo-mode (foo-mode 1))' cliche be documented as a
guideline? I found it after 1) reading Luc's email and 2) grepping the Lisp
directory to see how other libraries dealt with this issue.

At the least, if nothing special is done to treat non-nil :init-value, and
users need to do something additional themselves, then shouldn't the Info
doc show an example with non-nil :init-value, instead of the current example
using nil?

WRT the guideline of "loading must not change anything" - I agree, but I
think that turning on a minor mode is usually relatively benign, because it
can be turned off easily. Users loading a library that defines a minor mode
will not be shocked if the mode is turned on by default, if the logical
initial value to use is something other than nil.

Otherwise, if we're going to be rigid about this guideline (perhaps there
are good reasons to do that, even in this case), then maybe we should just
get rid of :init-value and have the initial value always be nil - that is,
make users of a library turn on the minor mode explicitly. That would not be
my preference, but it would at least avoid confusion.

Re: [drew.adams@oracle.com: Info on define-minor-mode - :init-value or :initial-value?]

[Luc Teirlinck]

Stefan Monnier wrote:

   > There is more.  You can not specify a non-nil :init-value, unless
   > either the minor mode is enabled by just setting the variable or
   > unless you do something extra.

   In what way is this a limitation?
   I.e. if you don't use define-minor-mode, how would you do it differently?
   [ I don't mean to say that "manual" code can't do it differently, but that
   if it does it differently, it'll most likely break the convention that just
   loading a file shouldn't make any visible changes. ]

Suppose that you have a minor mode that only makes a difference when
you are using the speedbar.  (I just take this as an example; any
option that is itself not enabled by default will do.)  The minor mode
would be part of the intended default behavior of speedbar, but not
everybody might like it, hence the need for a defcustom with default
t.  You use `custom-initialize-set' as the :initialize function.  You
put the minor mode code in speedbar.el.  Now loading speedbar.el will
enable the minor mode, unless the user overwrote that by setting the
minor mode variable to nil.  However, this will not change the behavior
of Emacs in any way that is unrelated to the speedbar.

With the current define-minor-mode code, you can _try_ to set the
:initialize keyword to `custom-initialize-set', but it will not work,
because define-minor-mode writes the defcustom before the minor mode
function, hence executing the defcustom will yield an error.  It is
possible to change the define-minor-mode code to get around that, but
I guess that it would require define-minor-mode to first write a
compiler defvar, then the mode function, and then the defcustom.
Also, all functions used by the minor mode function would have to be
defined before the define-minor-mode (if the minor mode is enabled by
default).

Sincerely,

Luc.

Re: [drew.adams@oracle.com: Info on define-minor-mode - :init-valueor :initial-value?]

[Luc Teirlinck]

Drew Adams wrote:

   WRT the guideline of "loading must not change anything" - I agree, but I
   think that turning on a minor mode is usually relatively benign, because it
   can be turned off easily. Users loading a library that defines a minor mode
   will not be shocked if the mode is turned on by default, if the logical
   initial value to use is something other than nil.

   Otherwise, if we're going to be rigid about this guideline (perhaps there
   are good reasons to do that, even in this case),

Emacs is completely inconsistent in how well it follows these
guidelines.

The _default_ :initialize function is custom-initialize-reset.  That
means that whenever a file containing a defcustom with a :set function
is loaded, that :set function is called _even_ if the user customized
the variable outside Custom, possibly in an attempt to avoid the :set
function.  In vain.  The `custom-initialize-reset' bully will force
the :set function on the user anyway.  This has repeatedly caused me
(and other people) problems in practice.  We have systematically dealt
with these problems on a one by one basis by overriding the default
with an explicit, more polite, :initialize function for those
defcustoms for which problems were reported.  But additional problems
keep popping up on a regular basis (see the `fringe-indicators'
thread).  The problems are often not that easy to trace down to
custom-initialize-reset, because they occur when a file is loaded and
for instance Custom loads tons of files behind the user's back.  The
reason for picking `custom-initialize-reset' as the default are
autoloaded defcustoms with a :set function.  But I believe that there
_must_ be other ways to deal with such defcustoms than the bullyish
custom-initialize-reset.

A second :initialize function is custom-initialize-set.  That one only
calls the :set function if the variable is still unbound.  This means
that, if nothing else, the user can avoid the :set function by setting
the variable outside Custom in his .emacs file.  (For preloaded
defcustoms, the user can undo the effects of the :set function in his
.emacs file.)  For non-preloaded defcustoms, even setting the variable
to its standard value avoids calling the :set function, which could be
useful, if you do not want the :set function to set a timer, hide some
text, make some text read-only or perform all kind of other
"courtesies" that :set functions like to do.

On the other hand, the only :set function considered safe for minor
modes is custom-initialize-default, which _never_ calls the :set
function on initialization.  This is completely inconsistent as the
minor-mode :set functions are usually benign compared to some other
:set functions that are out there.  (See `fringe-indicators' for a
really bad example of :set function abuse.)  Actually, the standard
:set function of define-minor-mode is one of the few classes of
functions for which even custom-initialize-reset would be safe.

So on the one hand I have trouble convincing people that we should
try to get rid (after the release) of custom-initialize-reset by
finding another solution for the autoload problem and on the other
hand, I have trouble convincing Stefan that the _much_ more benign
custom-initialize-set can be safe for minor modes that are natural to
enable by default.

Sincerely,

Luc.

Re: [drew.adams@oracle.com: Info on define-minor-mode - :init-valueor :initial-value?]

[Stefan Monnier]

>  (if foo-mode (foo-mode 1))

This will turn on the minor mode if you happen to browse the corresponding
customize group (because Custom will then load the file).
I.e. it'd be a bug.

> Otherwise, if we're going to be rigid about this guideline (perhaps there
> are good reasons to do that, even in this case), then maybe we should just
> get rid of :init-value and have the initial value always be nil - that is,
> make users of a library turn on the minor mode explicitly.  That would not be
> my preference, but it would at least avoid confusion.

That might be a good alternative.


        Stefan

Re: [drew.adams@oracle.com: Info on define-minor-mode - :init-value or :initial-value?]

[Stefan Monnier]

>> There is more.  You can not specify a non-nil :init-value, unless
>> either the minor mode is enabled by just setting the variable or
>> unless you do something extra.

>    In what way is this a limitation?
>    I.e. if you don't use define-minor-mode, how would you do it differently?
>    [ I don't mean to say that "manual" code can't do it differently, but
>    that if it does it differently, it'll most likely break the convention
>    that just loading a file shouldn't make any visible changes. ]

> Suppose that you have a minor mode that only makes a difference when
> you are using the speedbar.  (I just take this as an example; any
> option that is itself not enabled by default will do.)  The minor mode
> would be part of the intended default behavior of speedbar, but not
> everybody might like it, hence the need for a defcustom with default
> t.  You use `custom-initialize-set' as the :initialize function.  You
> put the minor mode code in speedbar.el.  Now loading speedbar.el will
> enable the minor mode, unless the user overwrote that by setting the
> minor mode variable to nil.  However, this will not change the behavior
> of Emacs in any way that is unrelated to the speedbar.

That's an interesting case indeed.
With define-minor-mode you'd have to add

  (if foo-mode (foo-mode 1))

at the end of the file.  It may not be the best solution, but it doesn't
seem much worse than using custom-initialize-set since it saves you from
having to worry about the ordering of defcustoms and defuns and it makes it
very clear that code is run at the toplevel and that it thus needs to be
checked for "no visible effect".


        Stefan

RE: [drew.adams@oracle.com: Info on define-minor-mode - :init-valueor :initial-value?]

[Drew Adams]

    >  (if foo-mode (foo-mode 1))

    This will turn on the minor mode if you happen to browse the
    corresponding
    customize group (because Custom will then load the file).
    I.e. it'd be a bug.

Sorry, I don't understand. If the variable is t, then the mode should be
turned on, no? Does it matter whether it is Customize or the user who loads
the file? The mode will be turned on only if the variable is t - why is that
bad? What am I missing?

And, as I said, I picked this up from the standard Lisp sources, so if it is
unadvisable then some updating might be in order.

If we don't get rid of :init-value (not my call), and the above code is
faulty, then what do you recommend to users writing libraries - just use nil
as the :init-value always?

Re: [drew.adams@oracle.com: Info on define-minor-mode - :init-valueor :initial-value?]

[Luc Teirlinck]

Stefan Monnier wrote:

   > Otherwise, if we're going to be rigid about this guideline (perhaps there
   > are good reasons to do that, even in this case), then maybe we should just
   > get rid of :init-value and have the initial value always be nil - that is,
   > make users of a library turn on the minor mode explicitly.  That would not be
   > my preference, but it would at least avoid confusion.

   That might be a good alternative.

No, because sometimes a standard value of t is appropriate and the
:init-value _has_ to reflect the standard value, or Custom would
consider the variable to be "rogue".

What if I just document in the Elisp manual what the acceptable
situations are for a non-nil :init-value and how it needs to be
handled:

pre-load the file containing the define-minor-mode before startup.el
and call the minor mode function (or custom-reevaluate-setting if the
minor mode only has to be enabled conditionally) in startup.el for
minor modes included with the Emacs distribution that affect Emacs
"globally" and put (if foo-mode (foo-mode 1)) at the end of the file
containing the define-minor-mode for minor modes that only affect
features defined in that file (and that are in files that are not
pre-loaded).

Sincerely,

Luc.

RE: [drew.adams@oracle.com: Info on define-minor-mode -:init-valueor :initial-value?]

[Drew Adams]

    What if I just document in the Elisp manual what the acceptable
    situations are for a non-nil :init-value and how it needs to be
    handled:

    pre-load the file containing the define-minor-mode before startup.el
    and call the minor mode function (or custom-reevaluate-setting if the
    minor mode only has to be enabled conditionally) in startup.el for
    minor modes included with the Emacs distribution that affect Emacs
    "globally" and put (if foo-mode (foo-mode 1)) at the end of the file
    containing the define-minor-mode for minor modes that only affect
    features defined in that file (and that are in files that are not
    pre-loaded).

FWIW, that's OK by me. In the user doc (Elisp), we should say "this is how
you create a minor mode..." and include the bit about (if foo-mode (foo-mode
1)) for non-nil init value. That is apparently an integral part of coding a
minor mode with a non-nil init value. If so, this should not be mentioned
only as an afterthought in an explanation of one of the examples.

And, since this is user doc, I would put the user bit first and the
"pre-load..." bit last, or remove the latter altogether. Most users reading
this will use define-minor-mode in their own libraries, not in stuff that is
part of Emacs. Or, if it is mentioned, perhaps mention it as a note to Emacs
maintainers/developers as an alternative for dealing with the issue in
internal code.

What about my suggestion of including this bit of code automatically, as
part of the expansion of define-minor-mode - perhaps by generating an
eval-after-load or something? Is that feasible? If so, would there be a
problem with such a hack?

Re: [drew.adams@oracle.com: Info on define-minor-mode -:init-valueor :initial-value?]

[Luc Teirlinck]

Drew Adams wrote:

   What about my suggestion of including this bit of code automatically, as
   part of the expansion of define-minor-mode - perhaps by generating an
   eval-after-load or something? Is that feasible? If so, would there be a
   problem with such a hack?

That is actually exactly what the define-minor-mode code used to do,
before Stefan started changing it.  (Stefan kept the eval-after-load,
but made it do different things).

However, using eval-after-load has many negative side effects, as I
pointed out before.

If one wants to have define-minor-mode enable a minor mode
automatically if :init-value is non-nil, then I believe that the best
way to do that would be to make define-minor-mode support alternative
:initialize functions like custom-initialize-set by changing the order
in which define-minor-mode defines things.  (As I suggested earlier.)

Sincerely,

Luc.

Re: [drew.adams@oracle.com: Info on define-minor-mode - :init-valueor :initial-value?]

[Richard M. Stallman]

    The _default_ :initialize function is custom-initialize-reset.  That
    means that whenever a file containing a defcustom with a :set function
    is loaded, that :set function is called

That seems like the right thing to me.  If the user set the variable,
he probably wanted to control the mode.

					    _even_ if the user customized
    the variable outside Custom, possibly in an attempt to avoid the :set
    function.

So what?  One can't please everybody.

      This has repeatedly caused me
    (and other people) problems in practice.

If you describe these problems, we could think about whether they are
worth solving by changing this mechanism.  However, if the problems
only occur with a few particularly troublesome variables, it would be
easier to deal with them one by one.

    hand, I have trouble convincing Stefan that the _much_ more benign
    custom-initialize-set can be safe for minor modes that are natural to
    enable by default.

It seems plausible to me.

     don't know how you'll decide to handle this, but I agree with Luc that it
    is confusing to set the :init-value to, say, `t' and then not see that
    initial value be effective.

I agree completely.

Stefan wrote:

    >  (if foo-mode (foo-mode 1))

    This will turn on the minor mode if you happen to browse the corresponding
    customize group (because Custom will then load the file).
    I.e. it'd be a bug.

Consider minor modes that work in the classical way: just setting the
variable enables the mode, and no :set-function is needed.  If the default
value is t, just loading the file will enable the mode.

What this means is that a minor mode's default value should never be t
unless t is a harmless value for it.

Once we decide that, there's no particular problem about :set
functions.  Regardless of whether the minor mode takes effect through
a :set function or just by setting the variable, either way, the
default value should be nil, unless for specific reasons t is
harmless.

Therefore, it is ok to run the :set function when the minor mode code
is loaded.  It is ok to use custom-initialize-reset for them.

    FWIW, that's OK by me. In the user doc (Elisp), we should say "this is how
    you create a minor mode..." and include the bit about (if foo-mode (foo-mode
    1)) for non-nil init value. That is apparently an integral part of coding a
    minor mode with a non-nil init value. If so, this should not be mentioned
    only as an afterthought in an explanation of one of the examples.

If we can't arrange to make just the defcustom do the job, documenting
this method is ok with me.

Perhaps we should document a simple way and a complex way.  The simple
way is that it all gets done by the :set function when the defcustom's
expansion is executed.  That requires putting the defcustom after the
minor mode function and generating a defvar before the function.
You'd use custom-initialize-reset.

For cases which are more complex, you'd use custom-initialize-default
and then write (if foo-mode (foo-mode 1)) at the end of the file.

Re: [drew.adams@oracle.com: Info on define-minor-mode - :init-valueor :initial-value?]

[Luc Teirlinck]

Richard Stallman wrote:

       The _default_ :initialize function is custom-initialize-reset.  That
       means that whenever a file containing a defcustom with a :set function
       is loaded, that :set function is called

   That seems like the right thing to me.  If the user set the variable,
   he probably wanted to control the mode.

In the text you quoted, I was talking about defcustoms with a :set
function that are _not_ minor modes.  The vast majority of minor modes
use custom-initialize-default, so the custom-initialize-reset problems
do not apply to them.

					       _even_ if the user customized
       the variable outside Custom, possibly in an attempt to avoid the :set
       function.

   So what?  One can't please everybody.

I thought that we decided that use of Custom was optional, that people
should be able to customize everything in their .emacs and completely
ignore Custom, if that is what they wanted to do.
custom-initialize-reset effectively makes the Custom way of
customizing things mandatory.  If you try to customize things manually
in your .emacs you subject yourself to Custom overriding you at random
moments, without notice, when some file is loaded (for instance by Custom).

	 This has repeatedly caused me
       (and other people) problems in practice.

   If you describe these problems, we could think about whether they are
   worth solving by changing this mechanism.  However, if the problems
   only occur with a few particularly troublesome variables, it would be
   easier to deal with them one by one.

Prior cases that were known to give problems have been solved already
in various ways, but people just keep writing new very intrusive :set
functions.  I have proposed a solution for one very bad example in a
different thread.  I plan to install that solution if I do not hear
any objections to it.

But custom-initialize-reset can give bad surprises to people
customizing a variable outside Custom, even for very reasonable :set
functions.  For instance, suppose that setting a variable only takes
effect if a timer is set.  People using Custom have come to expect
that just setting a variable through Custom is sufficient.  So you
have to provide a :set function that calls the timer.  Now somebody
who wants the feature sometimes enabled and sometimes not might set a
very complex value for the variable in his .emacs and then enable and
disable the feature for that complex value by repeatedly setting and
unsetting the (autoloadable) timer.  But every so often the feature
will be mysteriously silently enabled, when some file is silently
loaded, for instance by Custom.  (That is why, in defcustoms I write
that call a timer in a :set function, I usually use
custom-initialize-set, or, if the standard value does not require the
timer, custom-initialize-default.)

Sincerely,

Luc.

Re: [drew.adams@oracle.com: Info on define-minor-mode - :init-valueor :initial-value?]

[Luc Teirlinck]

Richard Stallman wrote:

   If we can't arrange to make just the defcustom do the job, documenting
   this method is ok with me.

   Perhaps we should document a simple way and a complex way.  The simple
   way is that it all gets done by the :set function when the defcustom's
   expansion is executed.  That requires putting the defcustom after the
   minor mode function and generating a defvar before the function.
   You'd use custom-initialize-reset.

   For cases which are more complex, you'd use custom-initialize-default
   and then write (if foo-mode (foo-mode 1)) at the end of the file.

If we are willing to change define-minor-mode, then I do not believe
that there is any need for the more complex method, unless there is
some reason why the define-minor-mode can not be delayed until all
functions called by the minor mode have been defined.

If we make define-minor-mode write a compiler defvar, then define the
mode function and then write the defcustom, one can use
custom-initialize-set if the define-minor-mode is not autoloaded, and
custom-initialize-reset if it is to be autoloaded.  Actually,
custom-initialize-reset is relatively harmless for the default
define-minor-mode :set function.  (The problems I was referring to
concern non minor mode :set functions, as I pointed out in my other
message.)

Sincerely,

Luc.

Re: [drew.adams@oracle.com: Info on define-minor-mode - :init-valueor :initial-value?]

[Juanma Barranquero]

On 7/31/05, Luc Teirlinck <teirllm@dms.auburn.edu> wrote:

> I thought that we decided that use of Custom was optional, that people
> should be able to customize everything in their .emacs and completely
> ignore Custom, if that is what they wanted to do.

Yes, please!

I for sure *don't* want Custom forcing its way on my variables.

-- 
                    /L/e/k/t/u

Re: [drew.adams@oracle.com: Info on define-minor-mode - :init-valueor :initial-value?]

[Richard M. Stallman]

       That seems like the right thing to me.  If the user set the variable,
       he probably wanted to control the mode.

    In the text you quoted, I was talking about defcustoms with a :set
    function that are _not_ minor modes.

I don't think this changes anything, but let's call it "behavior"
rather than "mode".

       So what?  One can't please everybody.

    I thought that we decided that use of Custom was optional, that people
    should be able to customize everything in their .emacs and completely
    ignore Custom, if that is what they wanted to do.

That is just a goal, not an unbreakable rule.  It seems irrelevant
to this issue anyway.  We're not talking about running Custom here.
We're talking about what happens when you load a defcustom and
the variable has already been set.

      If you try to customize things manually
    in your .emacs you subject yourself to Custom overriding you at random
    moments, without notice, when some file is loaded (for instance by Custom).

It's not Custom that's doing this, it is loading the defcustom.
Let's not complicate the issue unnecessarily.

    Prior cases that were known to give problems have been solved already
    in various ways, but people just keep writing new very intrusive :set
    functions.

We just have to fix them to be less intrusive.  Perhaps we could develop
a list of guidelines they should follow.

    For instance, suppose that setting a variable only takes
    effect if a timer is set.  People using Custom have come to expect
    that just setting a variable through Custom is sufficient.  So you
    have to provide a :set function that calls the timer.

Do you mean, that sets up the timer?

    Now somebody
    who wants the feature sometimes enabled and sometimes not might set a
    very complex value for the variable in his .emacs and then enable and
    disable the feature for that complex value by repeatedly setting and
    unsetting the (autoloadable) timer.

Do you mean activating and canceling the timer?  It seems like asking
for trouble.

      But every so often the feature
    will be mysteriously silently enabled, when some file is silently
    loaded, for instance by Custom.

The variable could have three states: an active timer, an inactive
timer, and nil meaning no timer has been set.  The set function could
create the timer only if the variable is nil.

Re: [drew.adams@oracle.com: Info on define-minor-mode - :init-valueor :initial-value?]

[Richard M. Stallman]

       For cases which are more complex, you'd use custom-initialize-default
       and then write (if foo-mode (foo-mode 1)) at the end of the file.

    If we are willing to change define-minor-mode, then I do not believe
    that there is any need for the more complex method, unless there is
    some reason why the define-minor-mode can not be delayed until all
    functions called by the minor mode have been defined.

Sometimes it is inconvenient to order things that way.  So let's
document this as an optional method.

Re: [drew.adams@oracle.com: Info on define-minor-mode - :init-valueor :initial-value?]

[Luc Teirlinck]

Richard Stallman wrote:

   Do you mean, that sets up the timer?

Yes.

   Do you mean activating and canceling the timer?

Yes.

	 But every so often the feature
       will be mysteriously silently enabled, when some file is silently
       loaded, for instance by Custom.

   The variable could have three states: an active timer, an inactive
   timer, and nil meaning no timer has been set.  The set function could
   create the timer only if the variable is nil.

That sounds complex, but anyway, the situation with timers is just one
example among many.  Using custom-initialize-set or
custom-initialize-default completely solves the timer problem as I
pointed out, so there is no need to come up with a more complex solution.

Sincerely,

Luc.

Re: [drew.adams@oracle.com: Info on define-minor-mode - :init-valueor :initial-value?]

[Juanma Barranquero]

On 8/1/05, Richard M. Stallman <rms@gnu.org> wrote:

> We're not talking about running Custom here.
> We're talking about what happens when you load a defcustom and
> the variable has already been set.

If loading a defcustom is gonna modify a variable I've set in my
.emacs, I want something akin to

  (please-defcustom-dont-fucking-touch 'my-variable)

whether this is

 (put 'my-variable 'saved-value t)

or anything else.

-- 
                    /L/e/k/t/u

Re: [drew.adams@oracle.com: Info on define-minor-mode - :init-valueor :initial-value?]

[Richard M. Stallman]

    If loading a defcustom is gonna modify a variable I've set in my
    .emacs, I want something akin to

      (please-defcustom-dont-fucking-touch 'my-variable)

Is there really such a problem, with the solution I've called for?