Re: Unicode/Mule (Re: null-device)

[Dave Love]

>>>>> "KE" == Karl Eichwalder <address@hidden> writes:

 KE> It was (and is?) Emacs creating those files.

Guessing what sort of thing that refers to, I'd be willing to bet on
its origin over a statistically significant sample – an insufficiently
notorious piece of obsolete Lisp that isn't part of Emacs, possibly
conflated with Naggum damage.

 KE> And Emacs 21.x is still clueless to detect this mess and to guide
 KE> the user to fix this files.

... as for data not marked as quoted printable, windows-1252 &c.
[Actually this must be about something different from what I assumed,
because Emacs can autodetect emacs-mule.]  A polite request for
assistance with that sort of thing in support of GNU-ish work would
probably work.

 KE> And then this rule "é" != "é" (in case you're using different
 KE> charsets).  Why doesn't this rule apply for "a", too?  I believe
 KE> I know the reason:  Emacs/Mule forces "western" users to accept
 KE> special far east assumptions.

You're apparently complaining about Mule's use of European-originated
international standards for European scripts¹.  As explained in the
published papers, ISO 2022 was the only real possibility then.  For
consistency you'd have to accuse X of the same².

The implied defamation of the implementors is quite out of order.  For
instance, in the absence of the helpful dealings I've had with handa &
al about Western stuff, it should at least be clear that the origin of
current support for Unicode in Emacs is far Eastern.

Otherwise, the Emacs source, its evaluator, and other published work
give the lie to much of the quasi-technical generalized logic³ you've
seen and are worth consulting.

 KE> The consequence is, Gnus often 

[I'd dispute ‘often’.]

 KE> thinks it has to create a multipart message...  

[Is that necessarily wrong?]

I'll eval into my message buffer

(string (make-char 'latin-iso8859-1 ?\xe9)
        (make-char 'latin-iso8859-14 ?\xe9)
        (make-char 'latin-iso8859-15 ?\xe9))
  => "ééé"

You may choose not to believe me that it results in a string with
three different Emacs characters and that Gnus will post this silently
in utf-8, but it's so.  I unify on encoding to utf-8 in what might as
well be a stock Emacs 21⁴.  For just the three ‘e’s, Latin-1 could
have been chosen.

What you normally see is not a consequence of Emacs forcing anything.
It can be customized.

 KE> Yes, it will only do so if you'll enter three 'y' (yes) in a row
 KE> -- this isn't "user-friendly" (Eli).

I made Gnus fixes in this general area (_not_ on the basis of bug
reports), at least some of which aren't installed.

Footnotes: 

¹ ECMA-35 (≡ISO-2022) is somewhere under <URL:http://www.ecma.ch/>,
  along with standards more-or-less corresponding to current ISO-8859.
  Note the ‘E’ in ECMA.

² OK, the author, ‘Scheifler’, might be far Eastern USA…

³ Proof by assertion, proof by intimidation &c.  The proof by racial
  abuse was only recently documented in the Annals of Generalized
  Logic.

⁴ I know Eli disagrees.

-- 
DOMINUS ILLUMINATIO MEA