Moving part of mule-base back into the XEmacs core (was Re: Building packages from source not quite possible)
David Starks-Browning <starksb(a)ebi.ac.uk> writes in xemacs-beta(a)xemacs.org:
On 12 Feb 99, Carsten Leonhardt writes:
> The files that are loaded from mule-base during dumping are only a
> subset of the contents of the mule-base package. They are 193kb
> uncompressed, 43603 bytes tared & gzipped. Does that size warrant
> these complications? (And the non-Mulers get the *.c files, anyway)
Speaking as a new xemacs user struggling with these issues...
If these size statistics are correct, I would be very happy as a
non-mule user to get this amount of extra baggage, if it meant
avoiding the complications for mule-users.
O.K. The dump-time Mule stuffs[1] get moved back into the core. This
means the grundgy code in core autoloads generation has got to be
restored so that autoloads generation doesn't blow chunks when run
with a non-Mule XEmacs binary. I can move the restored mule files
into their own subdirectory (lisp/mule), or ensure that they all have
a mule- prefix. Any preferences as to which?
Footnotes:
[1] Specifically mule-charset.el, mule-coding.el, mule-files.el,
mule-help.el, mule-category.el, mule-ccl.el, mule-misc.el, kinsoku.el,
mule-x-init.el, mule-tty-init.el, mule-cmds.el, arabic.el, chinese.el,
cyrillic.el, english.el, ethiopic.el, european.el, greek.el, hebrew.el,
japanese.el, korean.el, misc-lang.el, thai.el, viet-chars.el, vietnamese.el,
canna-leim.el, and mule-init.el.