Ar an ceathrú lá is fiche de mí Márta, scríobh Hrvoje Nikšić:
> Deprecating stuff when we don’t have an alternative is stupid,
IMHO.
It is my understanding that "un-define" and "unicode" are not merely
deprecated, but that they have always been unfinished, buggy, and
ultimately unsupported. [...]
And? That doesn’t mean we have an alternative.
> > Charming. Why do we ever fall back to
"iso-2022-jp" for things
> > we send over the wire? Signalling an error would be kinder to
> > the user and her correspondents.
>
> I believe we have at least one user in Japan, for whom that’s
> appropriate.
But it's inappropriate for those outside of Japan. I18N != Japanese
localization. Mule in most places reads like a Japanese localization
effort, which is part of the reason I never could stand it. That is,
of course, neither your nor Kyle's fault. My point is that we should
strive to remove such code, not add more of it. YMMV.
With that patch, if a UTF-8 coding system is available, and the user hasn’t
configured the app any further, then iso-2022-jp is never used, which is as
it should be.
If utf-8 isn’t available, signalling an error isn’t helpful to the user
either--cf. the complaints from the gnus lists from when gnus signalled that
error. The way to fix this situation is to _make_ utf-8 available within
XEmacs, which change 21.5 already has.
--
“I, for instance, am gung-ho about open source because my family is being
held hostage in Rob Malda’s basement. But who fact-checks me, or Enderle,
when we say something in public? No-one!” -- Danny O’Brien