From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.devel Subject: Re: How is the 21.2.90 pretest going? Date: Tue, 8 Oct 2002 20:05:14 +0900 (JST) Sender: emacs-devel-admin@gnu.org Message-ID: <200210081105.UAA17034@etlken.m17n.org> References: <15724.59040.131183.942957@mosaics.wustl.edu> <7458-Wed28Aug2002185639+0300-eliz@is.elta.co.il> <7458-Wed28Aug2002201929+0300-eliz@is.elta.co.il> <3405-Fri30Aug2002211052+0300-eliz@is.elta.co.il> <8011-Sat31Aug2002090148+0300-eliz@is.elta.co.il> <3791-Wed02Oct2002233515+0200-eliz@is.elta.co.il> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Trace: main.gmane.org 1034075414 4278 127.0.0.1 (8 Oct 2002 11:10:14 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 8 Oct 2002 11:10:14 +0000 (UTC) Cc: eliz@is.elta.co.il, emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 17ysFd-00016Z-00 for ; Tue, 08 Oct 2002 13:10:09 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17yt3A-0003vL-00 for ; Tue, 08 Oct 2002 14:01:20 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 17ysCB-0003Bn-00; Tue, 08 Oct 2002 07:06:35 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17ysB6-0002Un-00 for emacs-devel@gnu.org; Tue, 08 Oct 2002 07:05:28 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17ysB3-0002TD-00 for emacs-devel@gnu.org; Tue, 08 Oct 2002 07:05:27 -0400 Original-Received: from tsukuba.m17n.org ([192.47.44.130]) by monty-python.gnu.org with esmtp (Exim 4.10) id 17ysB2-0002P8-00; Tue, 08 Oct 2002 07:05:25 -0400 Original-Received: from fs.m17n.org (fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.11.6/3.7W-20010518204228) with ESMTP id g98B5EF28895; Tue, 8 Oct 2002 20:05:14 +0900 (JST) (envelope-from handa@m17n.org) Original-Received: from etlken.m17n.org (etlken.m17n.org [192.47.44.125]) by fs.m17n.org (8.11.3/3.7W-20010823150639) with ESMTP id g98B5ER12479; Tue, 8 Oct 2002 20:05:14 +0900 (JST) Original-Received: (from handa@localhost) by etlken.m17n.org (8.8.8+Sun/3.7W-2001040620) id UAA17034; Tue, 8 Oct 2002 20:05:14 +0900 (JST) Original-To: pot@gnu.org In-reply-to: (message from Francesco Potorti` on Tue, 08 Oct 2002 10:18:31 +0200) User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/21.1.30 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:8462 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:8462 In article , Francesco Potorti` 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 * 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 writes: > In article , Richard Stallman 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