Re: Char-related crashes (hopefully) fixed
Stephen J. Turnbull writes:
>>>>> "Hrvoje" == Hrvoje Niksic
<hniksic(a)iskon.hr> writes:
Hrvoje> Mule breaks too much to be worthy of so much consideration
Hrvoje> at this level.
I see it differently: Mule breaks too much to not get fixed. Mule
breaks so much that it needs to be fixed by design, not by patching
a few weak spots.
I agree with this.
The questions are what needs to be fixed and how, in what order.
Life
would be a lot easier for Mule fixers if there were no int-char. You
and Kyle are rightly objecting to that as a burden on the traditional
(ASCII -> Latin-1) developer/user base. So I'm looking for a
compromise. But because there are fundamental design problems in the
current Mule, we need to think about the transition to a sensible
design. That is going to break things; but if handled well the
transition can be a minimal burden.
Yes, we need a transition plan, but I don't think it necessarily
needs to break things. Right now we have the --with-mule
configuration option. We could leave MULE as it is and
essentially abandon it. We add a new configure option,
--with-i18n=MULE that gives access to the old MULE code for those
who want it or have apps that need it. --with-i18n=NEWGOOP can
build XEmacs with whatever the new design is. With this, we
don't break MULE code or non-MULE code. Stuff only breaks if you
build with --with-i18n=<something-other-than-no>, which is ideal
since it continues to let us roll releases during development.
I think using a name other than MULE for the new design will be
an overall win. The MULE name has baggage associated with it
that I think we want to be free of.
One simple fix is to remove Mule.
That is certainly not something I want to see.