From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.devel Subject: Re: desktop.el problem [Re: X-Symbol 4.0e; Emacs port (fwd)] Date: Tue, 30 Jul 2002 15:32:59 +0900 (JST) Sender: emacs-devel-admin@gnu.org Message-ID: <200207300632.PAA05930@etlken.m17n.org> References: <67B8CED503F3D511BB9F0008C75DAD660212AE84@dbwdfx17.wdf.sap-ag.de> <200207250247.LAA28221@etlken.m17n.org> <200207251807.g6PI7A007627@aztec.santafe.edu> <200207260157.KAA29953@etlken.m17n.org> <200207271852.g6RIqNk10666@aztec.santafe.edu> NNTP-Posting-Host: localhost.gmane.org X-Trace: main.gmane.org 1028010836 8852 127.0.0.1 (30 Jul 2002 06:33:56 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 30 Jul 2002 06:33:56 +0000 (UTC) Cc: christoph.wedler@sap.com, emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17ZQZs-0002Ic-00 for ; Tue, 30 Jul 2002 08:33:52 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17ZQrT-0004NA-00 for ; Tue, 30 Jul 2002 08:52:03 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17ZQaG-0007Va-00; Tue, 30 Jul 2002 02:34:16 -0400 Original-Received: from tsukuba.m17n.org ([192.47.44.130]) by fencepost.gnu.org with smtp (Exim 3.35 #1 (Debian)) id 17ZQZC-0007U1-00; Tue, 30 Jul 2002 02:33:10 -0400 Original-Received: from fs.m17n.org (fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.11.6/3.7W-20010518204228) with ESMTP id g6U6X3l26817; Tue, 30 Jul 2002 15:33:03 +0900 (JST) (envelope-from handa@m17n.org) Original-Received: from etlken.m17n.org (etlken.m17n.org [192.47.44.125]) by fs.m17n.org (8.11.3/3.7W-20010823150639) with ESMTP id g6U6Wx929418; Tue, 30 Jul 2002 15:33:03 +0900 (JST) Original-Received: (from handa@localhost) by etlken.m17n.org (8.8.8+Sun/3.7W-2001040620) id PAA05930; Tue, 30 Jul 2002 15:32:59 +0900 (JST) Original-To: rms@gnu.org In-Reply-To: <200207271852.g6RIqNk10666@aztec.santafe.edu> (message from Richard Stallman on Sat, 27 Jul 2002 12:52:23 -0600 (MDT)) 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:6167 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:6167 In article <200207271852.g6RIqNk10666@aztec.santafe.edu>, Richard Stallman writes: > The printed representation is just a multibyte sequence > starting by a new leading code assigned at the time of > defining the charset. > This new leading code can't be treated as valid in the next > session until the charset is defined in the same way as the > previous session. > This is a serious problem. It ought to be fixed. One possible fix is > to change print.c to use a hex escape for these characters. It can't be a fix. At the time of loading, such a hex escape will be decoded into an integer number, but as the number is invalid as a character code (before the corresponding charset is defined), the loader signals an error. > I will write the code if you tell me how to test for a character that > is in a nonstandard character set. Currently we don't have a mechanism to distinguish builtin charsets from user's charsets. I'll implement such a mechanism (not difficult) if it is really useful. --- Ken'ichi HANDA handa@etl.go.jp