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: desktop.el problem [Re: X-Symbol 4.0e; Emacs port (fwd)] Date: Thu, 25 Jul 2002 11:47:33 +0900 (JST) Sender: emacs-devel-admin@gnu.org Message-ID: <200207250247.LAA28221@etlken.m17n.org> References: <67B8CED503F3D511BB9F0008C75DAD660212AE84@dbwdfx17.wdf.sap-ag.de> 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 1027565321 5303 127.0.0.1 (25 Jul 2002 02:48:41 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 25 Jul 2002 02:48:41 +0000 (UTC) Cc: 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.33 #1 (Debian)) id 17XYgC-0001NQ-00 for ; Thu, 25 Jul 2002 04:48:40 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17XYvH-0006TR-00 for ; Thu, 25 Jul 2002 05:04:15 +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 17XYgL-0001uL-00; Wed, 24 Jul 2002 22:48:49 -0400 Original-Received: from tsukuba.m17n.org ([192.47.44.130]) by fencepost.gnu.org with smtp (Exim 3.35 #1 (Debian)) id 17XYfI-0001a8-00; Wed, 24 Jul 2002 22:47:45 -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 g6P2lcl08280; Thu, 25 Jul 2002 11:47:38 +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 g6P2lY904468; Thu, 25 Jul 2002 11:47:34 +0900 (JST) Original-Received: (from handa@localhost) by etlken.m17n.org (8.8.8+Sun/3.7W-2001040620) id LAA28221; Thu, 25 Jul 2002 11:47:33 +0900 (JST) Original-To: christoph.wedler@sap.com In-Reply-To: <67B8CED503F3D511BB9F0008C75DAD660212AE84@dbwdfx17.wdf.sap-ag.de> (christoph.wedler@sap.com) 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:6018 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:6018 In article <67B8CED503F3D511BB9F0008C75DAD660212AE84@dbwdfx17.wdf.sap-ag.de>, "Wedler, Christoph" writes: > Desktop also writes the contents of `kill-ring' and `register-alist', > and probably some history variables which could contain such > characters. Oops... 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. 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. Another workaround is not to save such strings that contains a characters of newly defined charsets. What do people think? I prefer the latter method because the former method is not robust. It won't be able to deal with the situation that a user defines a charset in his .emacs before .emacs.desktop is loaded. By the way, emacs-unicode won't have this problem. --- Ken'ichi HANDA handa@etl.go.jp