Re: Mule bugs: misidentification (Latin-1 vs. Chinese), revert issues

Nix writes: Article buffers are constructed, not read from files. I was referring to something read from outside. Gnus basically has the stance that Mule doesn't work so it's going to do it all itself; it doesn't bother to get things Mule-correct most of the time AFAICT. Could you send a build report the next time you build? M-x build-report RET. That way I'll have some idea what exactly your configuration is. If you're seeing ugly warnings, read the docs and set up the build-report Custom group so you can send a build log (ie, the output of make, with boring echoes of commands filtered out). As you surmise that should have nothing to do with it. Is there a reason to have "utf-8-bom" following "iso-8-1"? Basically, if the utf-8 detector doesn't catch it, and the iso-8-1 detector doesn't catch it, then the BOM detector won't either. OTOH, it's possible for there to be a file that looks like iso-8-1 based on character ranges but starts with the BOM (all of the octets in the BOM are valid ISO-8859 characters, at least in all the full-up sets like ISO-8859-1), which probably should be detected as UTF-8 *if* the other UTF-8 constraints are satisfied. I mean, how many text/plain files do you see that start with "" ?? (I suppose in Arabic or Cyrillic it might become something sensible. Do you read any of the non-Latin scripts?) Which is a long-winded way of saying, "if you have an empirical reason for this, it's probably an XEmacs bug!" _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta