[mew-int 01586] Re: windows 1252
Kazu Yamamoto ( 山本和彦 )
kazu at example.com
Tue Nov 4 11:13:34 JST 2003
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
More information about the Mew-int
mailing list