Mike FABIAN writes: > > I had planned to make available an XEmacs with Unicode as an > > internal encoding (and I have most of the necessary work for that on > > my disk), but I don’t think that is maintainable in the presence of > > both the Mule and the non-Mule compilation options (which means, in > > the presence of Unicode internally, four ./configure options with > > which everything needs to be tested when anyone makes any change > > that’s relevant to character encoding). And the elimination of the > > non-Mule compilation options has been vetoed, so it looks like users > > are stuck with the internal Mule encoding. > That is really a pity. I think it would be a big advantage to use > Unicode as an internal encoding. Yeah, it would, although IMO maintaining compatibility with Mule (NOT non-Mule) is what will be tedious and maybe tricky; a lot of user- visible Mule behavior depends on the charset abstraction. As far as "maintainability" goes, all he has to do is put it on a branch, and he can do anything he pleases.

But nobody (except me, and Bill Perry at my instigation) has ever been willing to do that. :-(