Re: How is the 21.2.90 pretest going?

Re: How is the 21.2.90 pretest going?

[Francesco Potorti`]

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

I am investigating the problem, and this is a partial report, done so
that people more knowledgeable than me may recognise the error before I
do.

During loadup, this form fails:
(load "international/ucs-tables")

The apparent reason is the use in ucs-tables of define-minor-mode, which
requires easy-mmode.  So I added:
(load "emacs-lisp/easy-mmode")

in loadup.el, before loading ucs-tables, but I still get a message
saying that it cannot load fns-VERSION.el.  I suspect that it needs yet
another file which I should load before easy-mmode.

I do not know if this is the correct way of proceeding, just letting you
know what's going on while I'm working on it.

Re: How is the 21.2.90 pretest going?

[Kenichi Handa]

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

Re: How is the 21.2.90 pretest going?

[Francesco Potorti`]

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

I had just finished writing the same workaround :-)

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

Ok.  I'll go on with the pretest, then.  If somewhere there is a list of
problems with the pretest, the text of your mail should go there.  

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

Re: How is the 21.2.90 pretest going?

[Richard Stallman]

    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

What is the bug in define-minor-mode in RC?

Re: How is the 21.2.90 pretest going?

[Francesco Potorti`]

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.

Re: How is the 21.2.90 pretest going?

[Stefan Monnier]

> 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

These comments have been obsolete since Emacs-21.1.


	Stefan

Re: How is the 21.2.90 pretest going?

[Richard Stallman]

    > 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

    These comments have been obsolete since Emacs-21.1.

I thought we decided define-minor-mode should still do this.
What makes the comments obsolete?

Re: How is the 21.2.90 pretest going?

[Stefan Monnier]

>     > 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
> 
>     These comments have been obsolete since Emacs-21.1.
> 
> I thought we decided define-minor-mode should still do this.
> What makes the comments obsolete?

They complained about the fact that the `define-minor-mode' code
had to be at the end because it ran (<mode> 1) if the variable
was non-nil.   I fixed it by using `eval-after-load' such that even
if the `define-minor-mode' code is in the middle of the file,
the (<mode> 1) call is only made at the end of the file.


	Stefan

Re: How is the 21.2.90 pretest going?

[Richard Stallman]

    During loadup, this form fails:
    (load "international/ucs-tables")

Do you have a file ucs-tables.elc?
Normally the definition of define-minor-mode is expanded
by the compiler.  If it is loading the source file,
that would have to expand the macro.