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: problem of define-minor-mode while bootstrapping Date: Mon, 23 Sep 2002 11:08:59 +0900 (JST) Sender: emacs-devel-admin@gnu.org Message-ID: <200209230208.LAA07889@etlken.m17n.org> References: <200209210157.KAA05776@etlken.m17n.org> <200209222254.g8MMs8I26785@rum.cs.yale.edu> 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 1032747127 28630 127.0.0.1 (23 Sep 2002 02:12:07 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 23 Sep 2002 02:12:07 +0000 (UTC) Cc: monnier+gnu/emacs@rum.cs.yale.edu, emacs-devel@gnu.org, d.love@dl.ac.uk Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 17tIhi-0007Rd-00 for ; Mon, 23 Sep 2002 04:12:06 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17tJNm-0000jh-00 for ; Mon, 23 Sep 2002 04:55:34 +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 17tIhi-0003xJ-00; Sun, 22 Sep 2002 22:12:06 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17tIez-0003Mz-00 for emacs-devel@gnu.org; Sun, 22 Sep 2002 22:09:17 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17tIew-0003IF-00 for emacs-devel@gnu.org; Sun, 22 Sep 2002 22:09:16 -0400 Original-Received: from tsukuba.m17n.org ([192.47.44.130]) by monty-python.gnu.org with esmtp (Exim 4.10) id 17tIev-0003I8-00 for emacs-devel@gnu.org; Sun, 22 Sep 2002 22:09:14 -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 g8N290K01535; Mon, 23 Sep 2002 11:09:00 +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 g8N290d16981; Mon, 23 Sep 2002 11:09:00 +0900 (JST) Original-Received: (from handa@localhost) by etlken.m17n.org (8.8.8+Sun/3.7W-2001040620) id LAA07889; Mon, 23 Sep 2002 11:08:59 +0900 (JST) Original-To: monnier+gnu/emacs@rum.cs.yale.edu In-reply-to: <200209222254.g8MMs8I26785@rum.cs.yale.edu> (monnier+gnu/emacs@rum.cs.yale.edu) 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:8108 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:8108 In article <200209222254.g8MMs8I26785@rum.cs.yale.edu>, "Stefan Monnier" writes: >> 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 ? Yes, but it works right just because (ucs-unify-8859 'encode-only) is explicitly called after loading ucs-tables.el. > 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. That's what I didn't know. When I see the previous code of define-minor-mode, I thought that it's the responsibility of define-minor-mode to synchronize the Emacs's status with :init-value. So, it appears to me that your change just gives it up. If it's the programmer's responsibility, it is cleaner that we have this line: (ucs-unify-8859 'encode-only) just after (define-minor-mode unify-8859-on-encoding-mode ...) in ucs-tables.el than having it in loadup.el. > If you want it to be automatic, then what's wrong with the code > suggested above to which you said "No" ? Because it doesn't solve the original problem, i.e., eval-after-load doesn't work at bootstrapping time. --- Ken'ichi HANDA handa@etl.go.jp