From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Jan D." Newsgroups: gmane.emacs.devel Subject: Re: Cut buffers and character encoding Date: Thu, 09 Nov 2006 20:10:50 +0100 Message-ID: <45537D3A.5080400@swipnet.se> References: <87y7qldq6h.fsf@pacem.orebokech.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1163099525 26107 80.91.229.2 (9 Nov 2006 19:12:05 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 9 Nov 2006 19:12:05 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 09 20:12:03 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 1GiFJN-0000lB-PN for ged-emacs-devel@m.gmane.org; Thu, 09 Nov 2006 20:11:42 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GiFJN-0001Ju-6U for ged-emacs-devel@m.gmane.org; Thu, 09 Nov 2006 14:11:41 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GiFIb-0000Zw-8D for emacs-devel@gnu.org; Thu, 09 Nov 2006 14:10:53 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GiFIY-0000UM-5k for emacs-devel@gnu.org; Thu, 09 Nov 2006 14:10:51 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GiFIX-0000Tb-TB for emacs-devel@gnu.org; Thu, 09 Nov 2006 14:10:50 -0500 Original-Received: from [81.228.9.184] (helo=av8-2-sn3.vrr.skanova.net) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GiFIX-0004s0-19 for emacs-devel@gnu.org; Thu, 09 Nov 2006 14:10:49 -0500 Original-Received: by av8-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 83FD038287; Thu, 9 Nov 2006 20:10:47 +0100 (CET) Original-Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av8-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 7055538283; Thu, 9 Nov 2006 20:10:47 +0100 (CET) Original-Received: from coolsville.localdomain (81-235-205-78-no59.tbcn.telia.com [81.235.205.78]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 297EB37E60; Thu, 9 Nov 2006 20:10:47 +0100 (CET) User-Agent: Thunderbird 1.5.0.7 (X11/20060918) Original-To: Romain Francoise In-Reply-To: <87y7qldq6h.fsf@pacem.orebokech.com> 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:62005 Archived-At: Romain Francoise skrev: > Hi, >=20 > I received a bug report about Emacs 22.0.90 stating that Emacs doesn't > do charset conversion when receiving text from a cut buffer. From the > report: >=20 > ,---- > | When I paste the cut buffer in an Emacs window in UTF-8 locales, Emac= s > | doesn't do any charset conversion. This problem occurs with both X an= d > | GTK versions. > | > | To reproduce the problem: > | 1. In UTF-8 locales: emacs -q > | 2. Open an xterm. > | 3. In the xterm, type '=E9=E8=EA'. > | 4. Select '=E9=E8=EA' in the xterm. > | 5. Quit the xterm (now, '=E9=E8=EA' is no longer in the primary selec= tion, > | only in the cut buffer, which Emacs supports). > | 6. Paste in Emacs (middle mouse button). > | > | I get: > | > | \351\350\352 > | > | instead of: > | > | =E9=E8=EA > `---- >=20 > This is in apparent contradiction to what the docstring of the > `selection-coding-system' variable says: >=20 > ,----[ C-h v selection-coding-system RET ] > | Documentation: > | Coding system for communicating with other X clients. > | When sending or receiving text via cut_buffer, selection, and clipboa= rd, > | the text is encoded or decoded by this coding system. > `---- >=20 The text encoding for cut buffers are defined to be ISO-Latin-1, so selection-coding-systemshould not have any effect. That said, we could d= ecode data from cut buffers from Latin-1 and encode to Latin-1 when putting dat= a in there. But cut buffers are obsolete anyway, so I vote for just fixing the documentation and leave it as is. Other suggestions? Jan D.