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