[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: code-pages.el
From: |
Dave Love |
Subject: |
Re: code-pages.el |
Date: |
01 Jan 2002 18:05:39 +0000 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.1.30 |
>>>>> Eli Zaretskii writes:
> AFAICS, it exports the same API and addresses the same
> functionality.
Apart from the construction macro, it only exports any API to avoid
damage from codepage.el. It essentially just defines coding systems
when it's loaded.
> Sorry, I don't follow: what display table hacking did you mean?
Things like latin1-disp and cyril-util do. [And latin1-disp should
probably offer the same transliterations as cyril-util.]
> Each cpNNN coding system defined by codepage.el has a plist which
> spells the language environment and the Mule charset supported by
> it. lisp/term/internal.el uses that plist to determine how to call
> cp-make-coding-systems-for-codepage, and which language environment
> to set up, given the value of dos-codepage.
I don't understand why that can't be done the same way as locale
processing.
> As for the Unicode vs Mule charsets issue, I don't think I mind
> that change,
I wish there was a consistent story on this. That was rejected
before, partly on the grounds it allegedly couldn't work, even.
> but I think we should turn on the unification on encoding and
> decoding when cpNNN is used, so that users could read text encoded
> in cpNNN and save it in iso8859-x, for example.
Unification on decoding is dangerous. For instance, it would screw Mule
developers, as documented; it also means reading/writing is likely not
to be idempotent. I don't turn it on.
I don't see what it has to do with cpNNN specifically, particularly as
I decode them in a unified form anyway. Obviously it isn't possible
to save cpnnn as 8859-N in general, but unifying on encoding is all
that's necessary to encode the compatible subset of a cpNNN charset.
That was vetoed.
There currently is no support installed for encoding arbitrary
(compatible) 8859 characters into the code-pages.el coding systems
(any more than there is for mac-roman or coding systems in
codepage.el). I used a simple `recode-coding-region' function to
recode text when developing.
It's actually possible that fragmenting Unicode on decoding (à la
Mule-UCS) is preferable, particularly for Cyrillic, and I have an
implementation.
> Those objections were in the context of the pretest which was
> deemed to be near its end, and the additional code, which is now
> installed, that was necessary to make the changes to codepages
> safe.
Perhaps, but something different was said, and should have applied
equally to handa's work.
> Can you write this and post the diffs here?
It already got advertised and discussed. I think Stefan posted diffs.
I don't know how much merging it needs and I don't remember why people
weren't happy with it.
- Re: code-pages.el,
Dave Love <=