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: Reporting UTF-8 related problems? Date: Tue, 30 Jul 2002 14:22:33 +0900 (JST) Sender: emacs-devel-admin@gnu.org Message-ID: <200207300522.OAA05828@etlken.m17n.org> References: <2110-Sun28Jul2002212621+0300-eliz@is.elta.co.il> <200207290518.OAA04004@etlken.m17n.org> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=ISO-2022-JP X-Trace: main.gmane.org 1028007508 3582 127.0.0.1 (30 Jul 2002 05:38:28 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 30 Jul 2002 05:38:28 +0000 (UTC) Cc: eliz@is.elta.co.il, 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 17ZPiF-0000vf-00 for ; Tue, 30 Jul 2002 07:38:27 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17ZPzp-0002xt-00 for ; Tue, 30 Jul 2002 07:56:37 +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 17ZPUX-0003gF-00; Tue, 30 Jul 2002 01:24:17 -0400 Original-Received: from tsukuba.m17n.org ([192.47.44.130]) by fencepost.gnu.org with smtp (Exim 3.35 #1 (Debian)) id 17ZPT2-0003Oq-00 for ; Tue, 30 Jul 2002 01:22: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 g6U5MYl26225; Tue, 30 Jul 2002 14:22:34 +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 g6U5MY929171; Tue, 30 Jul 2002 14:22:34 +0900 (JST) Original-Received: (from handa@localhost) by etlken.m17n.org (8.8.8+Sun/3.7W-2001040620) id OAA05828; Tue, 30 Jul 2002 14:22:33 +0900 (JST) Original-To: keichwa@gmx.net In-Reply-To: (message from Karl Eichwalder on Mon, 29 Jul 2002 17:35:41 +0200) 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:6165 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:6165 In article , Karl Eichwalder writes: > Kenichi Handa writes: >> I've just commited a change to ctext-post-read-conversion >> (in mule.el). > Thanks it mostly works for me. When I yank the phrase into Emacs using > the mouse, the right double quote becomes 2 letters wide (it look like a > space just before the quote: > Char: “ (0150310, 53448, 0xd0c8) point=309 of 321 (96%) column 12 This is because Emacs received this byte sequence: ESC $ ( B ! H "ESC $ ( B" is a designation sequence for jisx0208, and the following two bytes "! H" specifies the above Japanese symbol. This is a problem of lynx and galeon (or some core part of gnome, I don't know). > Another issue is you cannot kill and yank the quotation mark without > marking it first. I don't understand what do you mean. "kill and yank" from where to where? What is the meaning of "marking it"? >>> Doing the same from the Gnome web browser Galeon results in >> >>> ?Die Familie Schroffenstein? >> >>> (literal question marks instead of Unicode quotes). BTW, there is no >>> problem to paste from Galeon into an UTF-8 xterm. >> >> I tried the latest Galeon. It sends Emacs the same byte >> sequence as what lynx does. > Stil wondering why Emacs treet the quotes coming from Galeon different? No. I think your Galeon actually sent `?' to Emacs. My Galeon (ver.1.2.5) sends "ESC % G ... ESC % @". The ICCCM document distributed with XFree86 contains this paragraph (which doesn't exist in X.V11R6's document): ---------------------------------------------------------------------- UTF8_STRING as a type or a target specifies an UTF-8 encoded string, with NEWLINE (U+000A, hex 0A) as end-of-line marker. ---------------------------------------------------------------------- What I suspect is that UTF-8 xterm asks Galeon to send selection-data by UTF8_STRING (not by TEXT as Emacs does). --- Ken'ichi HANDA handa@etl.go.jp