GNU bug report logs - #6802
24.0.50; Yanking non-ASCII text from other X application leads to unicode escapes

Previous Next

Full log

View this message in rfc822 format

From: Štěpán Němec <stepnem <at> gmail.com>
To: "Jan D." <jan.h.d <at> swipnet.se>
Cc: kaloian <at> gnu.org, 6802 <at> debbugs.gnu.org, Kenichi Handa <handa <at> m17n.org>
Subject: bug#6802: 24.0.50; Yanking non-ASCII text from other X application leads to	unicode	escapes
Date: Thu, 28 Oct 2010 14:10:31 +0200

"Jan D." <jan.h.d <at> swipnet.se> writes:

> On 2010-08-10 04:29, Kenichi Handa wrote:
>> In article<4C603A4F.20006 <at> swipnet.se>, Jan Djärv<jan.h.d <at> swipnet.se> writes:
>>> Nowdays I think the
>>> default should be UTF8_STRING, and if that fails, try TEXT and then STRING.
>>
>> Why not COMPOUND_TEXT instead of TEXT above?  Please see the
>> docstring of x-select-request-type.
>
> I forgot about that.  It is better to try that before TEXT.
>
>>
>> Anyway, the current selection-related codes mix an abstract
>> layer (something like interprogram-cut/paste-function) and
>> X-specific layer in a chaos manner.  It seems that overhaul
>> and re-design is necessary.
>>
>
> It is a bit of a mess.  Separation of interprogram cut/paste and X selections
> would be nice.
>
> 	Jan D.

This is (and has been for quite a while now) a rather show-stopperish
bug. Is anybody working on fixing it?

(A refresher: you now get \u0ca0_\u0ca0 instead of ಠ_ಠ when pasting from
another X app.)

  Štěpán

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.