Re: code-pages.el

[Eli Zaretskii]

> From: address@hidden (Dave Love)
> Date: 21 Dec 2001 15:37:30 +0000
> 
> >>>>> Eli Zaretskii writes:
> 
>  > Then let's improve it instead of forking it.
> 
> This isn't a fork, it's completely different.

AFAICS, it exports the same API and addresses the same functionality.

>  > DOS (and Windows) can use the same general solutions that the other
>  > platforms use.  I don't see any inherent reason to have a sepcial
>  > solutions here.
> 
> Good.  Display table hacking should be likewise.

Sorry, I don't follow: what display table hacking did you mean?

>  > but that decoder didn't have the property list required by
>  > internal.el to load the right tables at startup.
> 
> I don't know what that is.

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.

Ideally, any new code for codepage support should keep those plists
for compatibility with internal.el.  But if it is deemed a good idea
to change that, like if the plist is removed, there should be a
corresponding change in internal.el to avoid breaking the MS-DOS port.

>  > If the replacement is fully compatible,
> 
> It's not fully compatible -- of necessity it uses mule-unicode which
> was the source of previous objections.

I meant the interface compatibility (the plist issue mentioned above).

As for the Unicode vs Mule charsets issue, I don't think I mind that
change, 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.

>  > I cannot possibly have any objections, can I?
> 
> I wouldn't like to say; I never understood the objections which
> previously made this `impossible to base an Emacs release on'

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.

>  > Could you please suggest changes to codepage.el which will merge in
>  > the functionality of code-pages.el?
> 
> I assume basically replacing it and making dummy versions of
> `codepage-setup', for instance.  Probably also splitting it up and
> allowing autoloading coding systems, which doesn't seem to have got
> anywhere.

Can you write this and post the diffs here?