[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#6802: 24.0.50; Yanking non-ASCII text from other X application leads
From: |
Štěpán Němec |
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 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) |
"Jan D." <jan.h.d@swipnet.se> writes:
> On 2010-08-10 04:29, Kenichi Handa wrote:
>> In article<4C603A4F.20006@swipnet.se>, Jan Djärv<jan.h.d@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
- bug#6802: 24.0.50; Yanking non-ASCII text from other X application leads to unicode escapes,
Štěpán Němec <=