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: Fri, 26 Jul 2002 10:57:45 +0900 (JST) Sender: emacs-devel-admin@gnu.org Message-ID: <200207260157.KAA29953@etlken.m17n.org> References: <67B8CED503F3D511BB9F0008C75DAD660212AE84@dbwdfx17.wdf.sap-ag.de> <200207250247.LAA28221@etlken.m17n.org> <200207251807.g6PI7A007627@aztec.santafe.edu> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Trace: main.gmane.org 1027648684 12287 127.0.0.1 (26 Jul 2002 01:58:04 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 26 Jul 2002 01:58:04 +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 17XuMl-0003C4-00 for ; Fri, 26 Jul 2002 03:58:03 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17XucK-00065w-00 for ; Fri, 26 Jul 2002 04:14:08 +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 17XuMx-0002Zs-00; Thu, 25 Jul 2002 21:58:15 -0400 Original-Received: from tsukuba.m17n.org ([192.47.44.130]) by fencepost.gnu.org with smtp (Exim 3.35 #1 (Debian)) id 17XuMV-0002Z1-00; Thu, 25 Jul 2002 21:57:47 -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 g6Q1vjl20026; Fri, 26 Jul 2002 10:57:45 +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 g6Q1vj911186; Fri, 26 Jul 2002 10:57:45 +0900 (JST) Original-Received: (from handa@localhost) by etlken.m17n.org (8.8.8+Sun/3.7W-2001040620) id KAA29953; Fri, 26 Jul 2002 10:57:45 +0900 (JST) Original-To: rms@gnu.org In-Reply-To: <200207251807.g6PI7A007627@aztec.santafe.edu> (message from Richard Stallman on Thu, 25 Jul 2002 12:07:10 -0600 (MDT)) User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/21.1.30 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) 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:6051 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:6051 In article <200207251807.g6PI7A007627@aztec.santafe.edu>, Richard Stallman writes: > Then, it's a general problem of desktop. If a user define a > new charset in a session, and there's a string containing > that charset in kill-ring, he always fails in the next > session while recovering the previous session. > Could you explain why this fails? What does the printed representation > of such a string look like, and how does it depend on having the character > set loaded? 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. > Perhaps we should change the printed representation of such strings so > that they can be read back in all circumstances. If characters in > user-defined character are written as \-sequences, would that do it? > It seems that the only way to solve it is to save also those > charset definitions. But, saving it in .emacs.desktop is > useless. We must save it in a file that is loaded before > .emacs.desktop is loaded. > Could you explain the reason for that? > Are these characters being output literally by prin1, > and then encoded when .emacs.desktop is saved? Yes. > If that is so, there are many points in that sequence that we could change. For instance? --- Ken'ichi HANDA handa@etl.go.jp