Re: code-pages.el

[Dave Love]

>>>>> Eli Zaretskii writes:

 > Then let's improve it instead of forking it.

This isn't a fork, it's completely different.

 >> (codepage.el duplicates some work done by cyrillic.el, at least.)

 > Then I suggest to merge them.

I suggested that before, along with bug fixes to the tables.  However,
I'm discussing improved Cyrillic support with handa.

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

 > IIRC, you suggested to replace one of the codepages with a cyrillic
 > decoder that supported the same encoding,

I offered essentially the code now installed, except that I've
commented out some Cyrillic coding systems in the installed version,
expecting to update cyrillic.el.

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

 > 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 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', given
that they had to apply equally to things that were installed.  The
only difference seemed to be who had implemented it.  Nothing material
has changed since then other than rms badgering me to install things.

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

Assumptions about special cases in codepage.el affect other code, but
I haven't yet asked handa about the relevant changes.