[mew-int 01585] Re: windows 1252

[Stephen J. Turnbull]

>>>>> "Eli" == Eli Zaretskii <eliz at example.com> writes:

    >> Date: Fri, 31 Oct 2003 21:39:16 +0900 (JST)

    >> From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)
    >> <kazu at example.com>

    >> Mew saves a buffer in Summary mode to a file as a cache. For
    >> this file, 'ctext is used.

    Eli> Doesn't the Summary buffer include only the Subject and From
    Eli> parts of the message?  If so, then they should not normally
    Eli> include any non-ASCII characters (it's contrary to the
    Eli> relevant RFC, IIRC).

Not really.  RFCs are about wire format; they are not relevant to
summary buffers or disk storage.  (Unless there is some reason, such
as digital signatures, that the on the wire format needs to be
preserved exactly.)

    Eli> If they do have non-ASCII characters,
    Eli> one could probably qp-encode them before writing the cache.

Why bother?

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

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.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.