Re: please consider emacs-unicode for pervasive changes

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

Richard Stallman <rms@gnu.org> 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.