[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