From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.devel Subject: Re: Cut buffers and character encoding Date: Fri, 10 Nov 2006 19:24:25 +0900 Message-ID: References: <87y7qldq6h.fsf@pacem.orebokech.com> <45537D3A.5080400@swipnet.se> <87mz70730i.fsf@pacem.orebokech.com> <45542D63.5070402@swipnet.se> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1163154269 23007 80.91.229.2 (10 Nov 2006 10:24:29 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 10 Nov 2006 10:24:29 +0000 (UTC) Cc: romain@orebokech.com, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 10 11:24:26 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1GiTYU-0007nc-DD for ged-emacs-devel@m.gmane.org; Fri, 10 Nov 2006 11:24:14 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GiTYT-0000Su-QW for ged-emacs-devel@m.gmane.org; Fri, 10 Nov 2006 05:24:13 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GiTY5-0000PP-PE for emacs-devel@gnu.org; Fri, 10 Nov 2006 05:23:49 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GiTY1-0000HV-W8 for emacs-devel@gnu.org; Fri, 10 Nov 2006 05:23:48 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GiTY1-0000H4-Pn for emacs-devel@gnu.org; Fri, 10 Nov 2006 05:23:45 -0500 Original-Received: from [150.29.246.133] (helo=mx1.aist.go.jp) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GiTY1-000241-44 for emacs-devel@gnu.org; Fri, 10 Nov 2006 05:23:45 -0500 Original-Received: from smtp3.aist.go.jp ([150.29.246.12]) by mx1.aist.go.jp with ESMTP id kAAANgOj021844; Fri, 10 Nov 2006 19:23:42 +0900 (JST) env-from (handa@m17n.org) Original-Received: by smtp3.aist.go.jp with ESMTP id kAAANawr018835; Fri, 10 Nov 2006 19:23:36 +0900 (JST) env-from (handa@m17n.org) Original-Received: from handa by etlken with local (Exim 3.36 #1 (Debian)) id 1GiTYf-00072J-00; Fri, 10 Nov 2006 19:24:25 +0900 Original-To: "Jan D." In-reply-to: <45542D63.5070402@swipnet.se> (jan.h.d@swipnet.se) User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/22.0.50 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:62024 Archived-At: In article <45542D63.5070402@swipnet.se>, "Jan D." wri= tes: > Romain Francoise skrev: > > "Jan D." writes: > >=20 >>> The text encoding for cut buffers are defined to be ISO-Latin-1, so >>> selection-coding-system should not have any effect. That said, we >>> could decode data from cut buffers from Latin-1 and encode to Latin-1 >>> when putting data in there. > >=20 > > Ah, thanks, you put me on the right track. > >=20 > > Emacs *does* decode the contents of the cut buffer in the > > `x-cut-buffer-or-selection-value' function, but it tries to decode them > > using `locale-coding-system' which is wrong if the locale is a UTF-8 > > locale... > >=20 > > The following patch fixes the problem for me, and if cut buffers are > > *always* iso-latin-1 then it should be the right thing. WDYT? > I've committed this change and the corresponding when writing to a cut bu= ffer. > I also changed the documentation you pointed out was wrong. I vaguely remember that I changed cut-buffer decoding to use locale-coding-system (if any) instead of iso-8859-1 upon a bug report from someone. He claimed that many X applications store a data encoded by the current locale in cut-buffer (even if that doesn't conform to ICCCM), thus it is better that Emacs also decodes it by the coding system specified by the locale. Even xterm, when run under, for instance, cs_CS.ISO8859-2 locale, stores ISO8859-2 characters as is in cut buffer. In the case of the origianl bug report, "=E9=E8=EA" is actually tried to be decoded by utf-8 and failed. Anyway, the documentation bug of selection-coding-system should be fixed. But, it may be good to use next-selection-coding-system even for cut buffer if it is set temporarily by C-x RET X. --- Kenichi Handa handa@m17n.org