For myself, contrarily to what I thought at first try, (latin-unity-install) did not solve the problem. So I have hacked lisp/gnus/mm-util.el with this patch : D:\Local\XEmacs\site-packages\lisp\gnus>diff -u mm-util.el~ mm-util.el --- mm-util.el~ Fri Sep 27 13:49:10 2002 +++ mm-util.el Fri Sep 27 19:58:08 2002 ＠＠ -531,6 +531,9 ＠＠ (mapcar 'mm-mime-charset (delq 'ascii (mm-find-charset-region b e)))))) + (if (and (memq 'iso-8859-1 charsets) + (memq 'iso-8859-9 charsets)) + (push 'iso-8859-15 charsets)) (if (and (memq 'iso-8859-15 charsets) (memq 'iso-8859-15 hack-charsets) (save-excursion (mm-iso-8859-x-to-15-region b e))) But this is ugly. Probably the truth is somewhere else. -- Fabrice

* Stephen J Turnbull <stephen(a)xemacs.org&gt; writes: Well, as long as I'm playing only with iso-8859-1, -9 and -15, the crude patch seems to do it. At least no more multipart messages. The real trick is that `charsets-in-region' and `charsets-in-string' seems to do it. If I look a little bit closer, here is what I find with 21.5.9: (loop with i = 1 while (< i 255) collect (progn (incf i) (char-charset i))) (ascii ... ascii control-1 ... control-1 latin-iso8859-1 ... latin-iso8859-1) All chars as expected are 8859-1 up to 255. However this one gives only 8859-9 : (mapcar #'char-charset '(?a ?z ?é ?è ?ç ?à ?ù ?£ ?€ ?â ?ô ?û ?î ?ä ?ü ?ë ?ï ?ö)) (ascii ascii latin-iso8859-9 ... latin-iso8859-9) Which is confirmed by the fact that : (mapcar #'char-int '(?a ?z ?é ?è ?ç ?à ?ù ?£ ?€ ?â ?ô ?û ?î ?ä ?ü ?ë ?ï ?ö)) (97 122 1641 1640 1639 1632 1657 1571 1700 1634 1652 1659 1646 1636 1660 1643 1647 1654) So the chars are actually read as 8859-9. Seems wrong to me. That should be better either 8859-1 or 8859-15. Or am I wrong ? -- Fabrice

* Stephen J Turnbull <stephen(a)xemacs.org&gt; writes: Fabrice> So the chars are actually read as 8859-9. Seems wrong to Fabrice> me. That should be better either 8859-1 or 8859-15. Or am I Fabrice> wrong ? I understand that. But what is the point in saying that (é) \'e is latin-9 ? It was latin-1 before being latin-9 ...

Fabrice> So the chars are actually read as 8859-9. Seems wrong to Fabrice> me. That should be better either 8859-1 or 8859-15. Or Fabrice> am I wrong ? Fabrice> I understand that. But what is the point in Xemacs saying Fabrice> that (é) \'e is latin-9 ? It was latin-1 before being Fabrice> latin-9 ... It's a quirk of the Mule implementation. Mule _must_ associate a charset with every character. This makes a politically noisy subset of Japanese happy, and in those pre-Unicode days it was a reasonable implementation strategy. Why Ben changed these associations for 21.5, I don't know. I suspect that what happens is that when the various character data is read in from etc/unicode/unicode-consortium/8859-*.TXT Mule's idea of the internal representation of the character gets changed every time it is mentioned and the last of those files to mention it wins. Ie, it's a bug in the new implementation. Some things never change. :-) -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN My nostalgia for Icon makes me forget about any of the bad things. I don't have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py

Thanks for following up. I'd forgotten about my patch.... Frank> No, Ben didn't change this. Everything worked perfect Frank> before Ben went to his holyday. It broke afterwards (In the Frank> last few weeks mainly). See my post starting this thread. Hm. Maybe I done it. I discussed the following patch with Ben before applying it, and he agreed it was the right thing in principle, but I doubt he reviewed it carefully, and he probably would not notice the kind of behavior change we're talking about (he doesn't use Gnus). It's the `add_charsets_to_precedence_list' hunk I suspect, if anybody wants to look at it. I'll try to get to this next week. 2002-06-23 Stephen J. Turnbull <stephen(a)xemacs.org&gt; * unicode.c: Improve top-level comments and many docstrings. (Fparse_unicode_translation_table): Use right function name in error. (unicode_to_ichar): Renamed from unicode_to_char. (Funicode_to_char): (decode_unicode_char): Use new name. (add_charsets_to_precedence_list): Change the dynarr argument instead of the global precedence list. (Funicode_precedence_list): New function. (Fset_language_unicode_precedence_list, Flanguage_unicode_precedence_list, Fset_default_unicode_precedence_list, Fdefault_unicode_precedence_list): Docstrings refer to docstring of Funicode_precedence_list. (set_unicode_conversion): Assert attempts to change Basic Latin (Unicode BMP, row 00). (Fset_unicode_conversion): Signal error on changes to Basic Latin. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN My nostalgia for Icon makes me forget about any of the bad things. I don't have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py

Frank> No, as I stated in my first post it was perfect at least Frank> until 2002-07-05 (that's the last build I still own which Frank> works completely as I want it) Don't take the ChangeLog dates too seriously; those are submission dates, not commit dates. However, my patch was committed before release of 21.5.7 on 2002-07-02 (possibly within the day), so that's too early unless you had a stale CVS tree lying around. Seems unlikely. Frank> Some when between this date and 2002-08-25 behavior Frank> changed: XEmacs now used ISO-8859-15 for both Frank> language-environments German and Latin-1 if I inputted any Frank> German "Umlaut" like ä, ö, ü, ß. At least for Latin-1 this Frank> was already a _severe_ bug. Maybe it's this one, then: 2002-05-28 Katsumi Yamaoka <yamaoka(a)jpl.org&gt; * mule/japan-util.el: Use `characterp' instead of `integerp' while defining char properties for katakana. * mule/mule-category.el: Clear the category table before defining categories for `predefined-category-list'. * mule/mule-cmds.el (finish-set-language-environment): Fit the charsets preferences in unicode conversions for the language environment. Suggested by ARISAWA Akihiro <ari(a)mbf.sphere.ne.jp&gt;. Despite the date it was probably committed on 2002-08-02, and definitely after the release of 21.5.8 on 2002-07-27. There were very few Mule-related changes in the period you focus on. If it isn't that one, it will take serious debugging. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN My nostalgia for Icon makes me forget about any of the bad things. I don't have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py

Hi, here I am. Those changes intended to make XEmacs 21.5 work under Japanese language environment. However, it considers now that only fixing japan-util.el can be a success. In Japanese language environment, though the other two changes aren't meaningless (that I think), it is insufficient to make XEmacs 21.5 perfect. Furthermore, I am uncertain about non-Japanese languages. Then, I'll withdraw them until Ben returns, how is it? Here's a reverse patch: -- Katsumi(a)Yamaoka.cc

Frank> Yes, this date matches. I seem to have build my first Frank> 21.5.8 on 2002-08-03 and it was already broken. Shall I get Frank> the last 21.5.7 from CVS, build it and have a look if it Frank> works? Then we would know, that it broke between 2002-07-27 Frank> and 2002-08-03. Better yet, try Katsumi's patch in this thread. You need to (1) patch or hand-edit the two files, (2) then do M-x byte-compile-and-load-file on each one, and you can test in a running XEmacs. Note that those files are dumped (IIRC); to get your XEmacs executable to reuse them, redump by removing xemacs.dmp (if you use --pdump) or xemacs(.exe) (if not) and running make. If that doesn't work, then you can try to isolate the patch using the "build different XEmacs going backward until it works" method (you can also use the -D ISODATE flag to cvs update). Don't do any more builds than you need to get a working XEmacs reasonably current for you; we've already got it down to "patches in (probably late) July". The constraint now is developer time to look at it, not information about the problem. :-( -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN My nostalgia for Icon makes me forget about any of the bad things. I don't have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py

Katsumi Yamaoka <yamaoka(a)jpl.org&gt; writes: I finally found time to try the reverse patch and it does indeed fix the problems for us Latin-x users, so I'd vote for applying it to 21.5. -- One Ring to rule them all, One Ring to find them, One Ring to bring them all and in the darkness bind them In the Land of Mordor where the Shadows lie.

Frank> Frank Schmitt <ich(a)Frank-Schmitt.net&gt; writes: Frank> No comments? Not from the people who understand that code. Ben and I are busy doing other things. The original contributor says he doesn't understand how it affects non-Japanese locales, which is damning. Ben should be back in action in a couple of weeks; he's currently coping with school, several months' mail backlog, and getting reacquainted with his workspaces. I've got a few last things to do with 21.4, and then I'm going to start working on these language environment issues. But I haven't worked directly on the devel branch in a year. It will take a while for me to spin up, especially since Ben has made significant changes to this code. None of the other currently active developers have done much work on this part of Mule. Frank> Nobody willing to put it into CVS? Not in these circumstances, no. Steve Y. approved the original patch, IIRC; ping him personally. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN My nostalgia for Icon makes me forget about any of the bad things. I don't have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py

Frank> This is just a revert to a state when everything worked, Frank> so I really don't see the problem. For you, everything worked. Obviously not so for Japanese. So patch your own copy of the sources as you like, and there will be an official patch which should make everybody happy in due time. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN My nostalgia for Icon makes me forget about any of the bad things. I don't have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py

Frank> (BTW: Couldn't you just do an ugly hack like Frank> (if (equal language-environment 'japan) Frank> (stuff from patch) Frank> (old-behavior) In 21.4, I'd strongly consider that (assuming the Japanese bug was considered important enough to fix in the first place). But in 21.5, we'd really like to get it right, even at the cost of some delay/ instability. Anyway, Ben is expected to be back in production shortly, so enjoy your period of relative peace while you can. He's got at least two projects pending, so I expect there will be crashes, broken builds and all the usual fun and mayhem until about Christmas. :-) -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN My nostalgia for Icon makes me forget about any of the bad things. I don't have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py