Aidan Kehoe <kehoea(a)parhasard.net> writes:
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.
What happens when those packages completely stop working, for whatever
reason? If we fail to fix the bug, then we're breaking VM. If we do
fix the bug, then they're not really unsupported, and my understanding
(along with my point) is invalidated. That point being, if something
is unsupported, then you don't add dependencies to it.
Also, un-define is very slow to load and takes a lot of memory. I
don't want it in my XEmacs unless I ask for it. VM should not load it
behind my back.
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.
Fair enough.
But if UTF-8 is always available, then why even have the iso-2022-jp
fallback?