From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Dave Love Newsgroups: gmane.emacs.devel Subject: Re: Several serious problems Date: 30 Aug 2002 00:09:02 +0100 Sender: emacs-devel-admin@gnu.org Message-ID: References: <200208190748.QAA14278@etlken.m17n.org> <200208291325.WAA03596@etlken.m17n.org> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1030662676 25602 127.0.0.1 (29 Aug 2002 23:11:16 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 29 Aug 2002 23:11:16 +0000 (UTC) Cc: monnier+gnu/emacs@rum.cs.yale.edu, keichwa@gmx.net, rms@gnu.org, emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 17kYRT-0006eb-00 for ; Fri, 30 Aug 2002 01:11:11 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17kYxx-000214-00 for ; Fri, 30 Aug 2002 01:44:46 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 17kYSr-0001ic-00; Thu, 29 Aug 2002 19:12:37 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17kYPe-0001NM-00 for emacs-devel@gnu.org; Thu, 29 Aug 2002 19:09:18 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17kYPY-0001MH-00 for emacs-devel@gnu.org; Thu, 29 Aug 2002 19:09:16 -0400 Original-Received: from albion.dl.ac.uk ([148.79.80.39]) by monty-python.gnu.org with esmtp (Exim 4.10) id 17kYPU-0001LH-00; Thu, 29 Aug 2002 19:09:09 -0400 Original-Received: from fx by albion.dl.ac.uk with local (Exim 3.35 #1 (Debian)) id 17kYPO-0001jE-00; Fri, 30 Aug 2002 00:09:02 +0100 Original-To: Kenichi Handa Original-Lines: 121 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:7134 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:7134 Kenichi Handa writes: > In article , > Dave Love writes: > > As far as I know, what's installed in the trunk behaves correctly, but > > I'm not using that code > > Why aren't you using that code? I don't want to use an unstable Emacs with all sorts of things I don't understand. > I noticed those `fixme's. Yes, it is better to solve all > of them, but, for the moment, I want to concentrate on > fixing the problem of RC. I was trying to sort out RC, but I don't understand this problem. > The safe-charsets property of utf-8 in RC is this: > > ascii eight-bit-control eight-bit-graphic latin-iso8859-1 > mule-unicode-0100-24ff mule-unicode-2500-33ff > mule-unicode-e000-ffff ethiopic tibetan thai-tis620 > katakana-jisx0201 ipa chinese-sisheng lao > vietnamese-viscii-lower vietnamese-viscii-upper I see: '((safe-charsets ascii eight-bit-control eight-bit-graphic latin-iso8859-1 mule-unicode-0100-24ff mule-unicode-2500-33ff mule-unicode-e000-ffff) in what appears to be revision 1.9.4.2 with sticky tag `EMACS_21_1_RC'. > It doesn't contain latin-iso8859-[23...]. Indeed. > The complaint is that the coding-system utf-8 can't encode > latin-2 characters in RC even if loadup.el has these lines. Indeed, but the complaint seemed to be that it could encode latin-2 and safe-charsets didn't say so. That's why I thought someone had changed it. > The reason is, as far as I see, the ccl program > `ccl-encode-mule-utf-8' doesn't have this line at the near > to head. > > (translate-character ucs-mule-to-mule-unicode r0 r1)) Yes. > So, even if we setup the translation table > `ucs-mule-to-mule-unicode' at loadup time, it is not used in > utf-8. Nor in other CCL coding systems. > Hmmm, I think I realized the situation of RC. It can unify > charsets between iso-8859-X, but utf-8 can't encode > iso-8859-X (intentionally), correct? Yes. > Richard, is it what you asked Dave to install for RC? I'm pretty sure ucs-tables was only allowed to be installed because just adding the file couldn't break anything. > I think RC should also allow utf-8 to encode 8859-X > correctly like in HEAD. I see no harm in it. I'm sure there's no harm in my Mule changes generally, but that's not what everyone has been told, unfortunately. > > I think I unilaterally added some other things (a utf-8 language > > environment and utf-16.el?) since they addressed somewhat misleading > > entries in PROBLEMS and the arguments against the Unicode support are > > either demonstrably wrong or spurious IMNSHO. > > I don't oppose to that. I didn't think you would. > I found one problem with utf-16. > It seems that utf-16-le/be can handle 8859-X correctly > because of this line in ccl-encode-mule-utf-16-le/be, > (translate-character ucs-mule-to-mule-unicode r0 r1) I guess that's an error, and I should have taken that out for consistency with utf-8. > > I'm afraid I've had enough of all this, > > Yah, you have done the excellent hack! I don't mean anything to do with useful work. It's after being told for so long it's impossible/broken/not wanted, wasting time, and then having to sort out the situation in adverse circumstances. It's very unfortunate not to have an active maintainer for Mule generally. > When I implemented translation table stuffs, I didn't expect that it > can be used this thoroughly. Strange! I thought that was exactly what they were for, and the only thing that was missing initially to satisfy the complaining Europeans was char-coding-system-table. The names were even `...-unification-...' originally. > I thought containing ucs-tables and etc in RC is at least > for making unify-on-encoding the default INCLUDING utf-8. I've no idea. As far as I remember, it was due to pressure from users of both Latin-1 and Latin-9 who must have actually tried it despite what they were told. I was surprised it was eventually allowed in.