Re: [mew-int 01585] Re: windows 1252

[山本和彦]

Hello all,

> If ctext is really preferred, there is a standard mechanism, the X
> Compound Text "extended segment", which Emacs should already know
> about.  In fact, I'd like to encourage the mew people to use that, so
> that there could actually be a non-abusive use of it for reference
> (this is the same mechanism that XFree86 abuses for ISO 8859/15
> selections).

If my understanding is correct, the ctext of Emacs implementation has
a private extension for Big5. That's why I said "ask developers to
extend ctext".

> That said, I think the sane thing for summary buffers is to use UTF-8
> as the encoding; the Unihan problem can be dealt with using a separate
> language field in the cache database, or guessed from the Content-Type
> header.

I should have explained the background earlier.

The reasons why Mew uses ctext for the Summary mode cache are:

(1) Backgourd compatibility to non-Mule Emacsen.

        Non-Mule Emacsen use 8bit as ISO-8859-1. Thus, to share the
        cache among Mule Emacsen and non-Mule Emacsen, we need to
        character set whose 8bit is ISO-8859-1.

(2) Co-exist of Emacs and XEmacs.

        The 'emacs-mule coding-system is not appropriate since XEmacs
        has a different internal representation from Emacs'one. Note
        Emacsen use different 'emacs-mule coding-system among
        versions.

The one-and-only coding-system which, I found, meets the requirements
above is 'ctext.

--Kazu