problem of define-minor-mode while bootstrapping

problem of define-minor-mode while bootstrapping

[Kenichi Handa]

The conference was over, and I re-started to work on
utf-8.el, ucs-tables.el, etc. of RC.

Dave Love <d.love@dl.ac.uk> writes:
> Richard Stallman <rms@gnu.org> writes:
>
>>     > Yes.  But, that mode is on by default in RC too.
>> 
>>     Gosh.  However, it appears to be done wrongly.  Custom will show it
>>     isn't on, and would turn it off if you tried to turn it on.  Surely if
>>     it's preloaded and meant to be the default, the defcustom initial
>>     value should just be changed.
>> 
>> That sounds right to me.  Can you send a patch?

>I should have said `define-minor-mode', not defcustom.  Just change
>:init-value nil to t and take out the function call from loadup.

I agree that is the right thing, but I found that if both
:global and :init-value are t, define-minor-mode doesn't
work while bootstrapping.

In that case, define-minor-mode calls eval-after-load, and
it calls load-symbol-file-load-history, and it tries to load
fns-XXX.el.  But, at bootstrapping time, fns-XXX.el is not
yet created.

Here's the last few lines of define-minor-mode.

       ;; If the mode is global, call the function according to the default.
       ,(if globalp
	    `(if (and load-file-name ,mode)
		 (eval-after-load load-file-name '(,mode 1)))))))

Could someone please fix this problem at first?

---
Ken'ichi HANDA
handa@etl.go.jp

Re: problem of define-minor-mode while bootstrapping

[Stefan Monnier]

> Here's the last few lines of define-minor-mode.
> 
>        ;; If the mode is global, call the function according to the default.
>        ,(if globalp
> 	    `(if (and load-file-name ,mode)
> 		 (eval-after-load load-file-name '(,mode 1)))))))
> 
> Could someone please fix this problem at first?

Update your sandbox, I've fixed it a few days ago AFAIK,


	Stefan

Re: problem of define-minor-mode while bootstrapping

[Kenichi Handa]

In article <200209191346.g8JDkdq07175@rum.cs.yale.edu>, "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

>>  Here's the last few lines of define-minor-mode.
>>  
>>         ;; If the mode is global, call the function according to the default.
>>         ,(if globalp
>>  	    `(if (and load-file-name ,mode)
>>  		 (eval-after-load load-file-name '(,mode 1)))))))
>>  
>>  Could someone please fix this problem at first?

> Update your sandbox, I've fixed it a few days ago AFAIK,

Do you mean this change?

	* emacs-lisp/easy-mmode.el (define-minor-mode): Add a :require arg.
	Don't call the function during init if mode is on by default.

***************
*** 224,230 ****
  			       (symbol-value ',keymap-sym))))
         
         ;; If the mode is global, call the function according to the default.
!        ,(if globalp
  	    `(if (and load-file-name ,mode)
  		 (eval-after-load load-file-name '(,mode 1)))))))
  \f
--- 227,233 ----
  			       (symbol-value ',keymap-sym))))
         
         ;; If the mode is global, call the function according to the default.
!        ,(if (and globalp (null init-value))
  	    `(if (and load-file-name ,mode)
  		 (eval-after-load load-file-name '(,mode 1)))))))


Could you please install it in RC too if that causes no
problem?

But, it seems that, with this, if :init-value is t, the
function to do various settings to make the mode work is
never called.

---
Ken'ichi HANDA
handa@etl.go.jp

Re: problem of define-minor-mode while bootstrapping

[Stefan Monnier]

> >>  Here's the last few lines of define-minor-mode.
> >>  
> >>         ;; If the mode is global, call the function according to the default.
> >>         ,(if globalp
> >>  	    `(if (and load-file-name ,mode)
> >>  		 (eval-after-load load-file-name '(,mode 1)))))))
> >>  
> >>  Could someone please fix this problem at first?
> 
> > Update your sandbox, I've fixed it a few days ago AFAIK,
> 
> Do you mean this change?
> 
> 	* emacs-lisp/easy-mmode.el (define-minor-mode): Add a :require arg.
> 	Don't call the function during init if mode is on by default.
> 
> ***************
> *** 224,230 ****
>   			       (symbol-value ',keymap-sym))))
>          
>          ;; If the mode is global, call the function according to the default.
> !        ,(if globalp
>   	    `(if (and load-file-name ,mode)
>   		 (eval-after-load load-file-name '(,mode 1)))))))
>   \f
> --- 227,233 ----
>   			       (symbol-value ',keymap-sym))))
>          
>          ;; If the mode is global, call the function according to the default.
> !        ,(if (and globalp (null init-value))
>   	    `(if (and load-file-name ,mode)
>   		 (eval-after-load load-file-name '(,mode 1)))))))
> 
> 
> Could you please install it in RC too if that causes no
> problem?
> 
> But, it seems that, with this, if :init-value is t, the
> function to do various settings to make the mode work is
> never called.

Do you mean that you'd rather see

	,(if globalp
	    `(if (and load-file-name (not (equal ,mode ,init-value)))
	         (eval-after-load load-file-name
	          '(,mode (if ,mode 1 -1)))))

I'm not sure it's worth the trouble.  The reason for this little piece
of code is so as to call (foo-mode 1) when people do (setq foo-mode t)
in their .emacs and then load foo-mode.el.
But people shouldn't use (setq foo-mode t), they should use (foo-mode 1)
instead anyway.
So I'd rather use that code less often rather than more often.


	Stefan

Re: problem of define-minor-mode while bootstrapping

[Kenichi Handa]

References: <200209191320.WAA03733@etlken.m17n.org> <200209191346.g8JDkdq07175@rum.cs.yale.edu>  <200209200006.JAA04300@etlken.m17n.org> <200209201838.g8KIc8t13414@rum.cs.yale.edu>
--text follows this line--
In article <200209201838.g8KIc8t13414@rum.cs.yale.edu>, "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:
>>  But, it seems that, with this, if :init-value is t, the
>>  function to do various settings to make the mode work is
>>  never called.

> Do you mean that you'd rather see

> 	,(if globalp
> 	    `(if (and load-file-name (not (equal ,mode ,init-value)))
> 	         (eval-after-load load-file-name
> 	          '(,mode (if ,mode 1 -1)))))

No.

> I'm not sure it's worth the trouble.  The reason for this little piece
> of code is so as to call (foo-mode 1) when people do (setq foo-mode t)
> in their .emacs and then load foo-mode.el.
> But people shouldn't use (setq foo-mode t), they should use (foo-mode 1)
> instead anyway.
> So I'd rather use that code less often rather than more often.

What I want is to make this work well at bootstrapping time
because now ucs-tables.el is preloaded.

(define-minor-mode unify-8859-on-encoding-mode
  "..."
  :group 'mule
  :global t
  :init-value t
  (if unify-8859-on-encoding-mode
      (ucs-unify-8859 t)
    (ucs-fragment-8859 t)))

When use-tables.el is loaded and this code run, it must run
(if ...) after setting the variable
unify-8859-on-encoding-mode to t.  Otherwise, the value of
unify-8859-on-encoding-mode doesn't synchronize with the
acutual status of the mode.

Before your change, define-minor-mode tried to run (if ...)
part through eval-after-load.  But, eval-after-load doesn't
work at bootstrapping time as I wrote before.

After your change, define-minor-mode never run (if ...),
which is worse.

Or, am I misunderstanding the functionality of
define-minor-mode?

---
Ken'ichi HANDA
handa@etl.go.jp

Re: problem of define-minor-mode while bootstrapping

[Stefan Monnier]

> > Do you mean that you'd rather see
> > 	,(if globalp
> > 	    `(if (and load-file-name (not (equal ,mode ,init-value)))
> > 	         (eval-after-load load-file-name
> > 	          '(,mode (if ,mode 1 -1)))))
> No.

Good ;-)

> > I'm not sure it's worth the trouble.  The reason for this little piece
> > of code is so as to call (foo-mode 1) when people do (setq foo-mode t)
> > in their .emacs and then load foo-mode.el.
> > But people shouldn't use (setq foo-mode t), they should use (foo-mode 1)
> > instead anyway.
> > So I'd rather use that code less often rather than more often.
> 
> What I want is to make this work well at bootstrapping time
> because now ucs-tables.el is preloaded.

Does it not work right now ?

> (define-minor-mode unify-8859-on-encoding-mode
>   "..."
>   :group 'mule
>   :global t
>   :init-value t
>   (if unify-8859-on-encoding-mode
>       (ucs-unify-8859 t)
>     (ucs-fragment-8859 t)))
> 
> When use-tables.el is loaded and this code run, it must run
> (if ...) after setting the variable
> unify-8859-on-encoding-mode to t.  Otherwise, the value of
> unify-8859-on-encoding-mode doesn't synchronize with the
> acutual status of the mode.

Sure.  That was the problem: unification was ON but
unify-8859-on-encoding-mode was still nil.  So I fixed the
init value to reflect reality.

> After your change, define-minor-mode never run (if ...),
> which is worse.

Why is it worse ?  It's the programmer's responsability to
make sure that the init-value is consistent with the state
of Emacs when the file is loaded.

If you want it to be automatic, then what's wrong with the code
suggested above to which you said "No" ?


	Stefan

Re: problem of define-minor-mode while bootstrapping

[Kenichi Handa]

In article <200209222254.g8MMs8I26785@rum.cs.yale.edu>, "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:
>>  What I want is to make this work well at bootstrapping time
>>  because now ucs-tables.el is preloaded.

> Does it not work right now ?

Yes, but it works right just because
	(ucs-unify-8859 'encode-only)
is explicitly called after loading ucs-tables.el.

> Why is it worse ?  It's the programmer's responsability to
> make sure that the init-value is consistent with the state
> of Emacs when the file is loaded.

That's what I didn't know.  When I see the previous code of
define-minor-mode, I thought that it's the responsibility of
define-minor-mode to synchronize the Emacs's status with
:init-value.  So, it appears to me that your change just
gives it up.

If it's the programmer's responsibility, it is cleaner that
we have this line:
	(ucs-unify-8859 'encode-only)
just after (define-minor-mode unify-8859-on-encoding-mode
...) in ucs-tables.el than having it in loadup.el.

> If you want it to be automatic, then what's wrong with the code
> suggested above to which you said "No" ?

Because it doesn't solve the original problem, i.e.,
eval-after-load doesn't work at bootstrapping time.

---
Ken'ichi HANDA
handa@etl.go.jp

Re: problem of define-minor-mode while bootstrapping

[Stefan Monnier]

> In article <200209222254.g8MMs8I26785@rum.cs.yale.edu>, "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:
> >>  What I want is to make this work well at bootstrapping time
> >>  because now ucs-tables.el is preloaded.
> 
> > Does it not work right now ?
> 
> Yes, but it works right just because
> 	(ucs-unify-8859 'encode-only)
> is explicitly called after loading ucs-tables.el.
> 
> > Why is it worse ?  It's the programmer's responsability to
> > make sure that the init-value is consistent with the state
> > of Emacs when the file is loaded.
> 
> That's what I didn't know.  When I see the previous code of
> define-minor-mode, I thought that it's the responsibility of
> define-minor-mode to synchronize the Emacs's status with
> :init-value.  So, it appears to me that your change just
> gives it up.

Well, it's just that I'm not sure which way it should work, I guess.

> If it's the programmer's responsibility, it is cleaner that
> we have this line:
> 	(ucs-unify-8859 'encode-only)
> just after (define-minor-mode unify-8859-on-encoding-mode
> ...) in ucs-tables.el than having it in loadup.el.

Maybe.  I have no opinion on that one.

> > If you want it to be automatic, then what's wrong with the code
> > suggested above to which you said "No" ?
> 
> Because it doesn't solve the original problem, i.e.,
> eval-after-load doesn't work at bootstrapping time.

Doesn't it ?  Why not ?


	Stefan

Re: problem of define-minor-mode while bootstrapping

[Kenichi Handa]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

>>  In article <200209222254.g8MMs8I26785@rum.cs.yale.edu>, "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:
>>  If it's the programmer's responsibility, it is cleaner that
>>  we have this line:
>>  	(ucs-unify-8859 'encode-only)
>>  just after (define-minor-mode unify-8859-on-encoding-mode
>>  ...) in ucs-tables.el than having it in loadup.el.

> Maybe.  I have no opinion on that one.

Ok, I'll fix it later.

>>  > If you want it to be automatic, then what's wrong with the code
>>  > suggested above to which you said "No" ?
>>  
>>  Because it doesn't solve the original problem, i.e.,
>>  eval-after-load doesn't work at bootstrapping time.

> Doesn't it ?  Why not ?

I wrote the reason in the first mail of this thread as below:
> In that case, define-minor-mode calls eval-after-load, and
> it calls load-symbol-file-load-history, and it tries to load
> fns-XXX.el.  But, at bootstrapping time, fns-XXX.el is not
> yet created.

---
Ken'ichi HANDA
handa@etl.go.jp

Re: problem of define-minor-mode while bootstrapping

[Stefan Monnier]

> >>  Because it doesn't solve the original problem, i.e.,
> >>  eval-after-load doesn't work at bootstrapping time.
> 
> > Doesn't it ?  Why not ?
> 
> I wrote the reason in the first mail of this thread as below:
> > In that case, define-minor-mode calls eval-after-load, and
> > it calls load-symbol-file-load-history, and it tries to load
> > fns-XXX.el.  But, at bootstrapping time, fns-XXX.el is not
> > yet created.

Huh?
AFAIK load-symbol-file-load-history and fns-XXX.el have been removed
from the trunk, so I don't understand why that would be a problem.


	Stefan

Re: problem of define-minor-mode while bootstrapping

[Kenichi Handa]

In article <200209241533.g8OFXib06640@rum.cs.yale.edu>, "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:
>>  >>  Because it doesn't solve the original problem, i.e.,
>>  >>  eval-after-load doesn't work at bootstrapping time.
>>  
>>  > Doesn't it ?  Why not ?
>>  
>>  I wrote the reason in the first mail of this thread as below:
>>  > In that case, define-minor-mode calls eval-after-load, and
>>  > it calls load-symbol-file-load-history, and it tries to load
>>  > fns-XXX.el.  But, at bootstrapping time, fns-XXX.el is not
>>  > yet created.

> Huh?
> AFAIK load-symbol-file-load-history and fns-XXX.el have been removed
> from the trunk, so I don't understand why that would be a problem.

Oops, I didn't notice it.  But, as I wrote before, I'm
working on the RC trunk, and thus want some fix in RC.

---
Ken'ichi HANDA
handa@etl.go.jp

Re: problem of define-minor-mode while bootstrapping

[Miles Bader]

On Fri, Sep 20, 2002 at 02:38:08PM -0400, Stefan Monnier wrote:
> The reason for this little piece of code is so as to call (foo-mode 1) when
> people do (setq foo-mode t) in their .emacs and then load foo-mode.el.
> But people shouldn't use (setq foo-mode t), they should use (foo-mode 1)
> instead anyway.
> So I'd rather use that code less often rather than more often.

CAn we just get rid of it?

That particular `feature' has always seemed like something just as likely to
cause confusion, as to actually help people.

-Miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: problem of define-minor-mode while bootstrapping

[Richard Stallman]

    > The reason for this little piece of code is so as to call (foo-mode 1) when
    > people do (setq foo-mode t) in their .emacs and then load foo-mode.el.
    > But people shouldn't use (setq foo-mode t), they should use (foo-mode 1)
    > instead anyway.
    > So I'd rather use that code less often rather than more often.

    CAn we just get rid of it?

I'd rather not do that.
It would be an incompatible change, and I don't see
enough reason for one.

Re: problem of define-minor-mode while bootstrapping

[Dave Love]

Richard Stallman <rms@gnu.org> writes:

>     > The reason for this little piece of code is so as to call (foo-mode 1) when
>     > people do (setq foo-mode t) in their .emacs and then load foo-mode.el.
>     > But people shouldn't use (setq foo-mode t), they should use (foo-mode 1)
>     > instead anyway.
>     > So I'd rather use that code less often rather than more often.
> 
>     CAn we just get rid of it?
> 
> I'd rather not do that.
> It would be an incompatible change, and I don't see
> enough reason for one.

The fact that you can't currently DTRT seems good enough.  I don't see
a serious problem with such a change since I, for one, wasn't aware
there was such code and the minor mode doc explicitly says that
setting the variable doesn't take effect.

It's also meant to be a requirement that just loading a library
doesn't change Emacs's state, particularly for the sake of Custom; I
think that's documented, but if not, it should be.

Re: problem of define-minor-mode while bootstrapping

[Richard Stallman]

    >     > The reason for this little piece of code is so as to call (foo-mode 1) when
    >     > people do (setq foo-mode t) in their .emacs and then load foo-mode.el.
    >     > But people shouldn't use (setq foo-mode t), they should use (foo-mode 1)
    >     > instead anyway.
    >     > So I'd rather use that code less often rather than more often.
    > 
    >     CAn we just get rid of it?
    > 
    > I'd rather not do that.
    > It would be an incompatible change, and I don't see
    > enough reason for one.

    The fact that you can't currently DTRT seems good enough.

Would you please be more specific?  I have no idea what that refers
to.  The start of this conversation was a week or more ago, and I
don't remember it.  What exactly is the RT that we can't D?

      I don't see
    a serious problem with such a change since I, for one, wasn't aware
    there was such code and the minor mode doc explicitly says that
    setting the variable doesn't take effect.

Could you show me the specific documentation?  Maybe it needs to be
fixed.

    It's also meant to be a requirement that just loading a library
    doesn't change Emacs's state, particularly for the sake of Custom; I
    think that's documented, but if not, it should be.

Could you explain more concretely what it is that you're thinking of
as a change in Emacs's state?  My memory is saying that this code was
designed to avoid an unwanted change in Emacs's state.

Re: problem of define-minor-mode while bootstrapping

[Dave Love]

Richard Stallman <rms@gnu.org> writes:

> Would you please be more specific?  I have no idea what that refers
> to.  The start of this conversation was a week or more ago, and I
> don't remember it.  What exactly is the RT that we can't D?

What handa's complaining about -- just define the minor mode
defaulting to on as far as I understand it.
> 
>       I don't see
>     a serious problem with such a change since I, for one, wasn't aware
>     there was such code and the minor mode doc explicitly says that
>     setting the variable doesn't take effect.
> 
> Could you show me the specific documentation?  Maybe it needs to be
> fixed.

E.g.:

   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!

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

> My memory is saying that this code was
> designed to avoid an unwanted change in Emacs's state.

I don't know what that refers to.

Re: problem of define-minor-mode while bootstrapping

[Richard Stallman]

    > Would you please be more specific?  I have no idea what that refers
    > to.  The start of this conversation was a week or more ago, and I
    > don't remember it.  What exactly is the RT that we can't D?

    What handa's complaining about -- just define the minor mode
    defaulting to on as far as I understand it.

That is very sketchy.  It is enough remind someone who already knows
the issue which issue is meant, but nowhere near enough to explain it
to a person who doesn't know.

Could someone explain to me what the issue is?

       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?

    > 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?

Re: problem of define-minor-mode while bootstrapping

[Kenichi Handa]

In article <E17v898-000334-00@fencepost.gnu.org>, Richard Stallman <rms@gnu.org> writes:
>>  Would you please be more specific?  I have no idea what that refers
>>  to.  The start of this conversation was a week or more ago, and I
>>  don't remember it.  What exactly is the RT that we can't D?

>     What handa's complaining about -- just define the minor mode
>     defaulting to on as far as I understand it.

> That is very sketchy.  It is enough remind someone who already knows
> the issue which issue is meant, but nowhere near enough to explain it
> to a person who doesn't know.

> Could someone explain to me what the issue is?

Ok, I'll repeast.

In RC, if both :global and :init-value of define-minor-mode
is non-nil, define-minor-mode calls eval-after-load as below:

       ;; If the mode is global, call the function according to the default.
       ,(if (and globalp (null init-value))
	    `(if (and load-file-name ,mode)
		 (eval-after-load load-file-name '(,mode 1)))))))

And, eval-after-load calls load-symbol-file-load-history,
and load-symbol-file-load-history loads "fns-XX.YY.ZZ.el".
But, at bootstrapping time, as "fns-XX.YY.ZZ.el" is not yet
generated, it signals an error.  It may not be a bug of
define-minor-mode, but a bug of eval-after-load or
load-symbol-file-load-history.  In any case, it should be
fixed at somewhere.

In HEAD instead, define-minor-mode now has this code:

       ;; If the mode is global, call the function according to the default.
       ,(if globalp
	    `(if (and load-file-name (not (equal ,init-value ,mode)))
		 (eval-after-load load-file-name '(,mode (if ,mode 1 -1))))))))

As (equal ,init-value ,mode) is t at bootstrapping time,
eval-after-load is not called, thus the above error is not
revealed.  But, as the result, it is now the programmer's
responsibility to make the XXX-minor-mode's status
synchronize to the value of XXX-minor-mode, i.e., we must do:

(define-minor-mode 'XXX-mode "" :global t :init-value t ...)
(XXX-mode 1)

I don't argue that this new behaviour is good or bad.  At
least, it is not a bug if properly described in the
docstring of define-minor-mode.

---
Ken'ichi HANDA
handa@m17n.org

Re: problem of define-minor-mode while bootstrapping

[Richard Stallman]

    In RC, if both :global and :init-value of define-minor-mode
    is non-nil, define-minor-mode calls eval-after-load as below:

	   ;; If the mode is global, call the function according to the default.
	   ,(if (and globalp (null init-value))
		`(if (and load-file-name ,mode)
		     (eval-after-load load-file-name '(,mode 1)))))))

    And, eval-after-load calls load-symbol-file-load-history,
    and load-symbol-file-load-history loads "fns-XX.YY.ZZ.el".
    But, at bootstrapping time, as "fns-XX.YY.ZZ.el" is not yet
    generated, it signals an error.

I looked at RC and found this code:

       ;; If the mode is global, call the function according to the default.
       ,(if globalp
	    `(if (and load-file-name ,mode)
		 (eval-after-load load-file-name '(,mode 1)))))))

As far as I can tell, the (null init-value) was never there.
Should I add it?

Anyway, I think the bug you found can be fixed this way:

       ;; If the mode is global, call the function according to the default.
       ,(if globalp
	    `(if (and load-file-name ,mode
		      (not purify-flag))
		 (eval-after-load load-file-name '(,mode 1)))))))

Does that fix work?

Re: problem of define-minor-mode while bootstrapping

[Kenichi Handa]

In article <200210180700.g9I70S7P015426@santafe.santafe.edu>, Richard Stallman <rms@gnu.org> writes:
> I looked at RC and found this code:

>        ;; If the mode is global, call the function according to the default.
>        ,(if globalp
> 	    `(if (and load-file-name ,mode)
> 		 (eval-after-load load-file-name '(,mode 1)))))))

> As far as I can tell, the (null init-value) was never there.

Oops, perhaps the code I quoted was from easy-mmode.el of
the version 1.42 of HEAD.  Sorry for the confusion.

> Should I add it?

No, I don't think so.

> Anyway, I think the bug you found can be fixed this way:

>        ;; If the mode is global, call the function according to the default.
>        ,(if globalp
> 	    `(if (and load-file-name ,mode
> 		      (not purify-flag))
> 		 (eval-after-load load-file-name '(,mode 1)))))))

> Does that fix work?

With this change, at least, setting :init-value to t doesn't
cause a trouble at bootstrapping time.

We still should have the code to turn that minor mode on
explicitely as below:

(define-minor-mode XXX-mode "..." :init-value t ...)
(XXX-mode 1)

But, I think that is ok because that is necessary only for a
preloaded file.

---
Ken'ichi HANDA
handa@m17n.org

Re: problem of define-minor-mode while bootstrapping

[Richard Stallman]

Thanks for working on this.

Re: problem of define-minor-mode while bootstrapping

[Dave Love]

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.

Re: problem of define-minor-mode while bootstrapping

[Richard Stallman]

    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.

Simply loading a file should not enable its features.
But if you first do something that explicitly
asks for its features to be enabled, then load the file,
that is a different issue entirely.  In this case, you are
not *just* loading the file.

It used to be that minor modes were always controlled by variables.
Setting or binding the variable was the way to enable the minor mode.
For user convenience, there were commands to do toggle or set the
variable.

As a result of define-minor-mode, this is not true any more.  There
are now some minor modes you cannot enable just by setting or binding
a variable.  But many minor modes still can be enabled that way.
Therefore, the ones that can't be enabled that way should have doc
strings to say so.

However, it is a useful feature that if the user just sets the
variable in .emacs before loading the file, that does manage
to enable the variable.

Re: problem of define-minor-mode while bootstrapping

[Stefan Monnier]

> > The reason for this little piece of code is so as to call (foo-mode 1) when
> > people do (setq foo-mode t) in their .emacs and then load foo-mode.el.
> > But people shouldn't use (setq foo-mode t), they should use (foo-mode 1)
> > instead anyway.
> > So I'd rather use that code less often rather than more often.
> 
> CAn we just get rid of it?

Many/most global minor modes did it by hand, so I added it
to define-minor-mode as well.  I have no need for that feature,
but since people did it by hand before, I suppose there was a
"good" reason for it.


	Stefan