Re: size of emacs executable after unicode merge

[Kenichi Handa]

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.

Yes.

> 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
address@hidden