Re: code-pages.el

[Dave Love]

>>>>> 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.