[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: size of emacs executable after unicode merge

From: Kenichi Handa
Subject: Re: size of emacs executable after unicode merge
Date: Thu, 06 Nov 2008 16:56:26 +0900
User-agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/23.0.60 (i686-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)

In article <address@hidden>, Stefan Monnier <address@hidden> writes:

> > I think it doesn't work.  Emacs needs that table and the other
> > mapping char-tables to decode non-ascii characters in files
> > that are loaded before dumping.

> IIUC Emacs only needs those tables when loading files that use some
> particular encodings.  E.g. it doesn't need it to read files using
> Unicode encodings.


> So couldn't we make sure all the files read during
> the dump are using Utf-8 or utf-8-emacs?  Isn't that already the case
> for all *.elc files?

Not yet, but such a change of encoding is easy.  The problem
is that lisp/international/characters.el setups syntax-table
and category-table for many characters by map-charset-chars.

Ex: (map-charset-chars #'modify-category-entry 'chinese-gb2312 ?c)

To know which (Unicode) characters belongs to
chinese-gb2312, Emacs has to load a mapping table.

> > If it is impossible to exclude garbage-colleted data (especially
> > char-tables) from the dumpled file, it seems that the only way is not
> > to build those char-tables.  But it requires rather heavy changes to
> > files loaded before dumped.

> What kind of changes?

The biggest one is for characters.el to solve the above
problem.  The others are for files that uses decode-char and
encode-char (e.g. japanese.el).  We can't use them in
pre-loaded files.

Kenichi Handa

reply via email to

[Prev in Thread] Current Thread [Next in Thread]