Re: \201 irritation! :-)

[Dave Love <d.love@dl.ac.uk>]

It's probably not really worth replying to Proof by Disingenuous Non
Sequitur per textbooks on Generalized Logic, but...

>>>>> "Rat" == Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

 Rat> I have yet to hear of any \201 bugs in any XEmacs built with
 Rat> MULE, 

Try paying more attention.

 Rat> and an XEmacs built without MULE cannot exhibit these bugs.

Presumably there's some problem with XEmacs/Mule that requires doing
that.  A unibyte Emacs doesn't generate emacs-mule coded text unless
there's a broken Mule-aware application running in it.  Anyone stating
otherwise should produce an evaluation in Emacs to back that up.

 Rat> Nothing about XEmacs throwing \201 bugs in gnu.emacs.gnus,
 Rat> nothing about \201 that I can recall in comp.emacs.xemacs.

Yes, people with a clue know that coding conversion errors in XEmacs
normally will result in ISO 2022 escapes -- as reported here -- or
just trashed non-ASCII characters.  There is no difference in
principle.  The vast majority of problems with Gnus are due to people
mistakenly running TM and possibly similar broken applications, as is
usually verifiable from their headers.  We see precious few bug
reports otherwise.  XEmacs users see \201 and other junk in Gnus for
various reasons, as in this thread.

 Rat> If that were true then there would be no appearance of \201.
 Rat> The fact that it did appear is proof that there are bugs in the
 Rat> FSF Emacs implementation of MULE, 

It's difficult to see how frobbing Gnus' coding conversion would fix
things if that wasn't rubbish.  It's there in the development history.
Genuine coding conversion bugs occur occasionally in quite obscure
circumstances and are fixed quickly, usually by Handa-san as they are
reported.  The record of bug reports and change logs shows so.

 Rat> and I will continue to offer XEmacs as a solution to those bugs
 Rat> until such time as they are fixed.

Do report on a single unfixed coding conversion bug in Emacs itself.
XEmacs/Mule isn't even available on the most widespread platform and
certainly has major known outstanding bugs which I've no wish to bash.
Hrvoje has written eloquently on the topic.

 Rat> And if your attitude accurately reflects that of the FSF
 Rat> then you'd better get used to me doing so, because while free
 Rat> software is important, software that works correctly is more
 Rat> important.

Lying about things isn't going to make any software work better.  I'm
baffled by the implication that XEmacs isn't free and anyone clueful
knows it has advantages over Emacs _and vice versa_.  As far as I
know, the attitude of the XEmacs maintainers is similar to that of the
Emacs maintainers -- soliciting reports of bugs and fixing them;
otherwise they make improvements, like importing Emacs Mule code and
techniques, so I suppose XEmacs is getting worse in Pieri's terms.
They don't appear to agree with him.