Re: How is the 21.2.90 pretest going?

[Kenichi Handa <handa@m17n.org>]

In article <E17ypZX-0000KQ-00@pot.cnuce.cnr.it>, Francesco Potorti` <pot@gnu.org> writes:

> While creating a pretest, at dump time I get an error, because
> lib-src/fns-VERSION.el is required before it is created.

Oops, while discussing about this problem (as the mail
attached at the tail), I forgot to install a temporary
workaround.  I've just installed it in RC.

2002-10-08  Kenichi Handa  <handa@m17n.org>

	* international/ucs-tables.el (unify-8859-on-encoding-mode): Set
	:init-value to nil, and calls (unify-8859-on-encoding-mode 1)
	later.

One bad result is that, the customize buffer of this
variable says as this:

Unify 8859 On Encoding Mode: Hide Toggle  on (non-nil)
   State: this option has been changed outside the customize buffer.

And, if you click "Erase Customization", the value is reset
to nil.

Once it is decided that this variable is removed and we
always enable unify-8859-on-encoding, this problem
disappears.  It disappears also when define-minor-mode or
eval-after-load is fixed in RC.

---
Ken'ichi HANDA
handa@m17n.org
Kenichi Handa <handa@m17n.org> writes:

> 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



> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://mail.gnu.org/mailman/listinfo/emacs-devel