From mboxrd@z Thu Jan 1 00:00:00 1970 Path: quimby.gnus.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [mew-int 00737] Re: (no subject) Date: Mon, 25 Feb 2002 08:55:36 +0200 (IST) Message-ID: NNTP-Posting-Host: quimby2.netfonds.no Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: quimby2.netfonds.no 1014620590 27394 195.204.10.66 (25 Feb 2002 07:03:10 GMT) X-Complaints-To: usenet@quimby2.netfonds.no NNTP-Posting-Date: 25 Feb 2002 07:03:10 GMT Cc: mew-int@mew.org, emacs-devel@gnu.org Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby2.netfonds.no with esmtp (Exim 3.12 #1 (Debian)) id 16fFAD-00077k-00 for ; Mon, 25 Feb 2002 08:03:10 +0100 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.33 #1 (Debian)) id 16fF7R-0004ft-00; Mon, 25 Feb 2002 02:00:17 -0500 Original-Received: from is.elta.co.il ([199.203.121.2]) by fencepost.gnu.org with esmtp (Exim 3.33 #1 (Debian)) id 16fF5R-0004Yv-00 for ; Mon, 25 Feb 2002 01:58:13 -0500 Original-Received: from is (is [199.203.121.2]) by is.elta.co.il (8.9.3/8.8.8) with SMTP id IAA06400; Mon, 25 Feb 2002 08:55:37 +0200 (IST) X-Sender: eliz@is Original-To: Kazu Yamamoto , Kenichi Handa In-Reply-To: <20020225.101129.117063194.kazu@iijlab.net> Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: quimby.gnus.org gmane.emacs.devel:1505 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:1505 On Mon, 25 Feb 2002, Kazu Yamamoto wrote: > From: Tak Ota > 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