Re: How is the 21.2.90 pretest going?

[Francesco Potorti` <pot@gnu.org>]

rms:
> What is the bug in define-minor-mode in RC?

Handa's mail explains it:

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

Francesco Potortì:
>     Probably define-minor-mode should be fixed in RC before releasing 21.3.
>     I found the following files mentioning a problem with that:
>      image-file.el
>      jka-compr.el
>      minibuf-eldef.el
>      mwheel.el
>      recentf.el

In those file I can read a comment like this:
 ;;; Note this definition must be at the end of the file, because
 ;;; `define-minor-mode' actually calls the mode-function if the
 ;;; associated variable is non-nil, which requires that all needed
 ;;; functions be already defined.  [This is arguably a bug in d-m-m]
 ;;;###autoload
 (define-minor-mode auto-image-file-mode

This is not the same problem as described by Handa, but it seems to be
related.  Sorry for not being more precise, but the inners of
make-minor-mode are at the edge of my elisp literacy, and I would need a
deeper study to understand it completely.

Here is a more complete description of the issue from a previous mail of
Handa's:

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