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: windows-1251 language environment Date: Tue, 14 Oct 2003 09:37:35 +0900 (JST) Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200310140037.JAA23889@etlken.m17n.org> References: <200310032356.54476.pogonyshev@gmx.net> <200310060013.52049.pogonyshev@gmx.net> <200310070254.LAA11795@etlken.m17n.org> NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1066092028 2200 80.91.224.253 (14 Oct 2003 00:40:28 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 14 Oct 2003 00:40:28 +0000 (UTC) Cc: pogonyshev@gmx.net, jasonr@f2s.com, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Tue Oct 14 02:40:23 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1A9DEd-0002FS-00 for ; Tue, 14 Oct 2003 02:40:23 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1A9DEd-0008Tb-00 for ; Tue, 14 Oct 2003 02:40:23 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1A9DDN-000299-Ij for emacs-devel@quimby.gnus.org; Mon, 13 Oct 2003 20:39:05 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1A9DCk-0001vu-3V for emacs-devel@gnu.org; Mon, 13 Oct 2003 20:38:26 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1A9DCC-0001bB-74 for emacs-devel@gnu.org; Mon, 13 Oct 2003 20:38:23 -0400 Original-Received: from [192.47.44.130] (helo=tsukuba.m17n.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1A9DCB-0001Z2-AH for emacs-devel@gnu.org; Mon, 13 Oct 2003 20:37:51 -0400 Original-Received: from fs.m17n.org (fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.11.6p2/3.7W-20010518204228) with ESMTP id h9E0bah05469; Tue, 14 Oct 2003 09:37:36 +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.6/3.7W-20010823150639) with ESMTP id h9E0bZs18653; Tue, 14 Oct 2003 09:37:36 +0900 (JST) Original-Received: (from handa@localhost) by etlken.m17n.org (8.8.8+Sun/3.7W-2001040620) id JAA23889; Tue, 14 Oct 2003 09:37:35 +0900 (JST) Original-To: d.love@dl.ac.uk In-reply-to: (message from Dave Love on Fri, 10 Oct 2003 18:11:46 +0100) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:17068 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:17068 In article , Dave Love writes: > Kenichi Handa writes: >> At first, I have installed a mechanism of auto-loading a >> coding system. > Is it really worth it for the 8-bit sets? I'm not sure whether to > think this is significant or not: > let ((stats (garbage-collect))) > (load "code-pages") > (pp (list stats (garbage-collect)))) It's not easy to see the effect of preloading code-pages from this output. But, when I put this in loadup.el (load "international/code-pages") the resulting Emacs is 585K-byte bigger. I think we can't ignore this size. >> I have not yet tested it fully. We may have to add GCPROs >> in several places. > > was reasonably well tested, probably also on a system where gcpro was > relevant then (though I don't know if I tested it by forcing GC during > loading). Stefan also showed me his implementation. I reached my code because I didn't want to change anything other than the place related to coding-system. That is because this mechanism is obsolte in emacs-unicode in which defining a coding system is so cheap that there's no need of this mechanism. >> Right. I think what we need for language environment is a >> mechanism similar to face; i.e. creating a new one easily >> while allowing inheriting, and customizing an existing one >> easily. > I did something about customizing the language alist some time ago. > As far as I remember, it naturally used the mechanism for overriding > elements of the standard value in customized lists, and that interface > was vetoed for reasons I didn't understand. Presumably inheritance > would use a similar mechanism, but I'm not sure how useful it is. > As it is, a language environment has to cover several things that > should be orthogonal: > * The language (which might influence input methods as well as the > default Ispell dictionary, at least); > * The charset/coding system preferences (which might also influence > input methods, though the hooks now in Quail make that less of an > issue); > * Other things that currently aren't dealt with properly, like paper > size (for ps-print), calendar holidays &c (which may depend on the > locale territory, not just the language). >> For instance, in such a case, we can allow people to create >> a new lang. env. by inheriting, for instance, Russian, and >> modifying coding-system to windows-1251. > Is this actually better than allowing them to specify (the equivalent > of) the locale ru_RU.windows-1251? If that locale is available to a user, that is ok. Otherwise, there should be a way to provide the same environment to him. --- Ken'ichi HANDA handa@m17n.org