emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: please consider emacs-unicode for pervasive changes


From: Dave Love
Subject: Re: please consider emacs-unicode for pervasive changes
Date: 06 Sep 2002 00:59:12 +0100
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Richard Stallman <address@hidden> writes:

>     RMS complained about even chaneglogs getting changed,
> 
> I recall these changes but not what caused them.  Were they caused by
> the emacs-unicode branch?

Yes, in the case you complained to me about (on the branch, and it was
actually edits of handa's did originally).  However, I seem to
remember there were other problems, probably due to people using
unification-on-decode, contrary to the warnings.

> If so, what exactly was the nature of the change that occurred?  Was
> the change a matter of replacing one correct iso-2022 representation
> with a different but equally correct representation for the same
> characters?

Yes, since it was Latin-1 v. Latin-2 if I remember correctly.  If it
had been Chinese v. Japanese, it might not have been correct.

>                                                         but it will
>     certainly screw various Emacs 21 lisp/{international,language} files.
> 
> As part of convertng Emacs to use unicode for most characters,
> won't we also change these files to use unicode?

They mostly haven't been touched, and don't need to be.  You can't
generally change them to Unicode (as opposed to utf-8-emacs) because
they may contain non-Unicode characters.  Also, if you want, say, to
maintain the distinction between Japanese and Chinese in HELLO, you
don't want to unify that.

> So they won't be clobbered.

If anyone else starts working on that code, they better understand the
issues anyhow...

> Editing the non-unicode Emacs 21 files might change them, indeed.

(Those and similar files.)  That's just what I'm warning about.

> Is this an inevitable consequence of the unification done by
> Unicode?

No.  The fact that you can't prevent it for i/o of general iso-2022 is
a missing feature, as handa said.  (Not that I know the design for
that.)  I thought it was a design feature you insisted on that the
character space is much bigger than Unicode for that sort of reason.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]