Re: [mew-int 00737] Re: (no subject)

[Eli Zaretskii]

On Mon, 25 Feb 2002, Kazu Yamamoto wrote:

> From: Tak Ota <address@hidden>
> Subject: [mew-int 00737] Re: (no subject)
> 
> > Therefore many buffers in Mew sets ctext-unix as the default coding
> > system.  However, I have no idea how this decision was made.
> 
> Yes, this is intentional. 
> 
> Ctext is only character set which can conver ISO-2022 related
> character sets and ISO-8859-1.
> 
> If we use US-ASCII and 8bit portion of ctext, this is identical to
> ISO-8859-1. This is friendly to non-mule EMacs, Emacs --unibyte for
> example.

Handa-san, it sounds like the new encoding with ICCM Extended Segments 
support should not be called ctext, because ctext is used in file I/O, at 
least by Mew.  It sounds like we should leave ctext as it was working 
before, including the fact that it didn't support the ICCCM Extended 
Segments, and use another name (e.g., compound-text-with-extensions) for 
the new coding system.  We will then have to make that new coding system 
be the default for X selections in CVS head.

Do you agree?

> So, to my best knowledge, ctext is only the character set which can
> survive in the old Emacs world and the multilingual Emacs world.

It was IMHO an unfortunate decision to use ctext for file I/O, since 
ctext must support the ICCCM spec which is inappropriate for encoding 
anything but X selections.  However, given that Mew uses that for quite 
some time, Emacs shouldn't break it, I think.

> (1) Since selective-display is not used anymore, another separator
> rather than CR can be used. ctext will be sufficient.
> 
> (2) Even if we continue to use CR, ctext-unix is necessary only for
>     Summary mode. ctext is enough for other buffers.

The -unix part is not the problem.  The problem is that ctext was changed 
in Emacs CVS to support Extended Segments, in accordance with the ICCCM 
spec (because some versions of X are using that ICCCM feature to encode 
ISO8859-15 characters in selections).  That change in ctext caused it to 
call pre-write-conversion function which couldn't handle being called on 
a string.

While I can (and most probably shall) fix the new coding system to be 
able to be called from write-region, there are other subtle aspects of 
the new coding system that make it inappropriate for file I/O.  So I 
think we had better leave the original ctext alone.