* Re: [mew-int 00737] Re: (no subject)
2002-02-23 23:11 ` Tak Ota
@ 2002-02-25 1:11 ` Kazu Yamamoto
2002-02-25 6:55 ` Eli Zaretskii
0 siblings, 1 reply; 4+ messages in thread
From: Kazu Yamamoto @ 2002-02-25 1:11 UTC (permalink / raw)
From: Tak Ota <Takaaki.Ota@am.sony.com>
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.
Of course, Emacs (--multibyte) can read ctext.
So, to my best knowledge, ctext is only the character set which can
survive in the old Emacs world and the multilingual Emacs world.
Since Mew uses the CR character as a separator in Summary mode (for
historical reasons:: selective-display was used), ctext-unix is
necessary. (CR MUST not be converted to LF).
What I can say is as follows:
(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.
--Kazu
_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [mew-int 00737] Re: (no subject)
2002-02-25 1:11 ` [mew-int 00737] " Kazu Yamamoto
@ 2002-02-25 6:55 ` Eli Zaretskii
0 siblings, 0 replies; 4+ messages in thread
From: Eli Zaretskii @ 2002-02-25 6:55 UTC (permalink / raw)
Cc: mew-int, emacs-devel
On Mon, 25 Feb 2002, Kazu Yamamoto wrote:
> From: Tak Ota <Takaaki.Ota@am.sony.com>
> 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.
_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [mew-int 00737] Re: (no subject)
@ 2002-02-25 7:10 Kenichi Handa
2002-02-26 16:52 ` Eli Zaretskii
0 siblings, 1 reply; 4+ messages in thread
From: Kenichi Handa @ 2002-02-25 7:10 UTC (permalink / raw)
Cc: kazu, mew-int, emacs-devel
Eli Zaretskii <eliz@is.elta.co.il> writes:
> 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.
Considering this situation, I agree with the name change.
---
Ken'ichi HANDA
handa@etl.go.jp
_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [mew-int 00737] Re: (no subject)
2002-02-25 7:10 [mew-int 00737] Re: (no subject) Kenichi Handa
@ 2002-02-26 16:52 ` Eli Zaretskii
0 siblings, 0 replies; 4+ messages in thread
From: Eli Zaretskii @ 2002-02-26 16:52 UTC (permalink / raw)
Cc: kazu, mew-int, emacs-devel
> Date: Mon, 25 Feb 2002 16:10:20 +0900 (JST)
> From: Kenichi Handa <handa@etl.go.jp>
>
> >> 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.
>
> Considering this situation, I agree with the name change.
I made the change in CVS head. (It isn't required in the RC, since I
didn't change the names there to begin with.)
_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2002-02-26 16:52 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-02-25 7:10 [mew-int 00737] Re: (no subject) Kenichi Handa
2002-02-26 16:52 ` Eli Zaretskii
-- strict thread matches above, loose matches on Subject: below --
2002-02-23 16:11 ctext-pre-write-conversion barfs Tak Ota
2002-02-23 18:51 ` (no subject) Eli Zaretskii
2002-02-23 23:11 ` Tak Ota
2002-02-25 1:11 ` [mew-int 00737] " Kazu Yamamoto
2002-02-25 6:55 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).