Your message dated Sun, 11 May 2003 20:40:13 +1000
with message-id <[EMAIL PROTECTED]>
and subject line Removed
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--------------------------------------
Received: (at submit) by bugs.debian.org; 17 Jun 2001 01:01:36 +0000
>From [EMAIL PROTECTED] Sat Jun 16 20:01:36 2001
Return-path: <[EMAIL PROTECTED]>
Received: from surfchem0.riken.go.jp [::ffff:134.160.25.161]
by master.debian.org with esmtp (Exim 3.12 1 (Debian))
id 15BQwa-0004Sl-00; Sat, 16 Jun 2001 20:01:36 -0500
Received: from surfchem0.riken.go.jp (localhost [127.0.0.1])
by surfchem0.riken.go.jp (Postfix) with ESMTP id 009D51C112
for <[EMAIL PROTECTED]>; Sun, 17 Jun 2001 10:06:56 +0900 (JST)
Date: Sun, 17 Jun 2001 10:06:51 +0900
Message-ID: <[EMAIL PROTECTED]>
From: Tomohiro KUBOTA <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: emacs20-dl: copy&paste problem
Mail-Reply-To: [EMAIL PROTECTED]
User-Agent: Wanderlust/1.1.1 (Purple Rain) EMY/1.13.8 (Tastes differ)
FLIM/1.13.2 (Kasanui) APEL/10.2 Emacs/20.7 (i386-debian-linux-gnu) MULE/4.1
(AOI)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Delivered-To: [EMAIL PROTECTED]
package: emacs20-dl
version: 20.7-7
Please inform this report to the upstream.
A bug report for GNU Emacs with X selection (i.e., copy&paste).
My Environment
- Debian GNU/Linux "Sid" (unstable, developing version) i386.
- GNU libc 2.2.3
- XFree86 4.0.3
- GNU Emacs 20.7.2
What I do?
1. Invoked Emacs without -nw.
2. Type C-h H to display many languages on Emacs.
3. By drugging mouse with pushing left button, Choose three
Japanese characters (Ni-Hon-Go) which mean "Japanese language".
4. Go to Rxvt (compiled with multibyte language support) and
push middle button of mouse, to paste the characters.
5. I found "(BF|K\8lB" is inserted instead of correct Japanese
three characters. This is the bug.
6. Reproductivity: paste into Xedit (distributed with XFree86)
results in beep and ">> ILLEGAL SELECTION <<" in Xedit window.
Not only Japanese words but also Chinese (traditional and
simplified), Korean, Russian, and Greek also fails.
Analysis
I inserted a hook code into XChangeProperty() of libX11 to report
the content of "data" parameter. When I selected the three
Japanese characters of Ni-Hon-Go and pasted it into Rxvt,
the hook code reported (in hexadigimal)
data=1b 24 28 42 46 7c 4b 5c 38 6c 1b 28 42
Since Rxvt requires selection in COMPOUND_TEXT format, this
is a COMPOUND_TEXT byte sequence which Emacs generated.
The first four bytes means "designate JIS X 0208 into G0".
Following six bytes are JIS X 0208 expression of Japanese
three characters. The last three bytes means "designate
US ASCII into G0". Paste into Xedit, not Rxvt, made the
same byte sequence.
Rxvt receives the byte sequence using XmbTextPropertyToTextList()
function. I checked the return value of the function and
found it returns three. This means that XmbTextPropertyToTextList()
failed to process the last three bytes. Then Rxvt thinks
the selection byte sequence is illegal and falls into pasting
the raw byte sequence. This is the cause of the bug behavior.
I tested with many selections from Emacs and found that
all non-ASCII and non-ISO-8859-1 selections have a final
escape to designate ASCII in G0 and ISO-8859-1 in G1.
Here, to fix this bug behavior, we can consider three ways.
1. Modify Emacs not to generate the final escape sequence.
2. Modify X11 library (XmbTextPropertyToTextList()) to ignore
the final escape sequence.
3. Modify X clients (many!) to ignore positive return value
of XmbTextPropertyToTextList().
I think 3 is bad beacuse positive return value may be caused
by really illegal sequence. Then, which of 1 or 2?
COMPOUND_TEXT is described in xc/doc/specs/CTEXT/CTEXT.txt
in XFree86 (or X.org) distribution. Though it mentions
the *initial* state, it doesn't mention about the final
state. Thus, Emacs doesn't need to set the final state
into ASCII + ISO8859-1.
In conclusion, I think Emacs should be modified to fix this bug.
---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
http://www.debian.or.jp/~kubota/
"Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/
---------------------------------------
Received: (at 101160-done) by bugs.debian.org; 11 May 2003 10:41:57 +0000
>From [EMAIL PROTECTED] Sun May 11 05:41:56 2003
Return-path: <[EMAIL PROTECTED]>
Received: from bangpath.uucico.de [195.71.9.197]
by master.debian.org with esmtp (Exim 3.12 1 (Debian))
id 19EoGg-0005NI-00; Sun, 11 May 2003 05:41:23 -0500
Received: by bangpath.uucico.de (Postfix, from userid 10)
id 7EB6A26B2C; Sun, 11 May 2003 12:41:21 +0200 (CEST)
Received: by regression.cyrius.com (Postfix, from userid 1000)
id 41E2423D48; Sun, 11 May 2003 20:40:13 +1000 (EST)
Date: Sun, 11 May 2003 20:40:13 +1000
From: Martin Michlmayr <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Removed
Message-ID: <[EMAIL PROTECTED]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4i
Delivered-To: [EMAIL PROTECTED]
X-Spam-Status: No, hits=-7.3 required=4.0
tests=BAYES_01,USER_AGENT_MUTT
version=2.53-bugs.debian.org_2003_05_09
X-Spam-Level:
X-Spam-Checker-Version: SpamAssassin 2.53-bugs.debian.org_2003_05_09
(1.174.2.15-2003-03-30-exp)
This package has been removed from Debian unstable because it has been
orphaned for a very long time and nobody adopted it. See
http://lists.debian.org/debian-devel-announce/2003/debian-devel-announce-200304/msg00005.html
for more information.
--
Martin Michlmayr
[EMAIL PROTECTED]
