Re: Unicodification of sources, part 1

Aidan> The reason I haven’t proposed anything remotely like this Aidan> up to now is that once we’re at the point where the Aidan> release branch has been stable for a while and has good Aidan> support for UTF-8, we can deprecate 21.4 and do all the Aidan> things you listed in a week, without the need for a Aidan> parallel set of Mule packages. Which would seem to be more Aidan> economic of effort. *Deprecating 21.4* (in the sense of ending the promise to try to support packages on it) is also probably a minimum of 24 months away, and the parallel set of Mule packages is also many months away. I'd like to start moving in that direction soon. Aidan> Mike’s point about the impact on 21.4 equally applies to Aidan> SXEmacs; At the moment, SXEmacs is not our problem, and it's in any case quite a different problem, since 21.4 is going to be obsoleted in the (vaguely ;-) foreseeable future, while (selfish desire for more manpower aside ;-) I certainly hope that's not true for SXEmacs. Aidan> I think the best way to support Unicode on 21.4 and SXEmacs Aidan> would be to port over Ben’s 21.5 Unicode support, I tend to disagree. The 21.5 Unicode support is seriously twisted around Windows support and the whole Mule infrastructure. SXEmacs doesn't want any Windows baggage, and probably could benefit from losing Mule, too. 90% of the Mule-related C code seems to be devoted to variable-width character gymnastics. "Why should we impose on them a burden which we ourselves are unable to carry?" If SXEmacs wants Unicode, I think their best path is to rip out Mule support and support Unicode directly with fixed-width buffers. They can use Ben's codecs, or even port Python's architecture. They'll be unable to compete in the "stubborn Mule" market, sure, but do they really want to when there's both GNU Emacs and XEmacs to serve that niche? Only my two yen, of course; but if Steve et cie. are interested in my opinion, that's it. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.