"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes:
>>>>> "Hrvoje" == Hrvoje Niksic
<hniksic(a)srce.hr> writes:
Hrvoje> "Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes:
>> MULE! File-coding! byte-, short-, and word- buffers!
Hrvoje> All of these (except for possibly byte-coding) subtly
Hrvoje> affect existing code, rather than being separate globs of
Hrvoje> code to load or unload. These are not areas where modules
Hrvoje> can help, sorry.
If MULE is "subtly affecting existing code" this is a bad thing.
Why? In this case, "subtly affecting existing code" doesn't apply to
source code; most of the differences are hidden with the clever use of
preprocessor macros. While to a careless observer it may seem that
Mule code looks "the same" in both Mule and non-Mule cases, the fact
is that compiled code differs wildly.
My point is: no, you cannot dynamically load or unload sets of C
preprocessor macros, sorry.
MULE probably can't be localized, but I for one would like to see
it
tried;
See above.
Making people who have little direct interest in MULE conform to
complex coding conventions that they don't understand is bad. If
functions that must be MULE-aware could be localized to a smaller
set of modules, it would be a good thing.
You can't localize general concepts like "characters are not 1 byte".
If third-party contributors don't understand Mule coding conventions,
too bad for them. Besides, the conventions are not all that complex,
once you get to know them -- which goes for the rest of the XEmacs C
sources.
Olivier Galibert was working on the possibility of different buffer
alignments, with what result I don't know.
I didn't say there cannot be parallel Mule implementations in a single
source tree. I only think that it is impossible to have parallel Mule
implementations in a single XEmacs binary.