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

Previous Next

Full log

Message #23 received at 6802 <at> debbugs.gnu.org (full text, mbox):

From: Kenichi Handa <handa <at> m17n.org>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: eliz <at> gnu.org, kaloian <at> gnu.org, 6802 <at> debbugs.gnu.org
Subject: Re: bug#6802: 24.0.50; Yanking non-ASCII text from other X application
	leads to	unicode	escapes
Date: Tue, 10 Aug 2010 11:29:48 +0900

In article <4C603A4F.20006 <at> swipnet.se>, Jan Djärv <jan.h.d <at> swipnet.se> writes:

> Eli Zaretskii skrev 2010-08-09 18.34:

> > Why does x-get-selection default to 'STRING?  Is that sensible
> > behavior?

I just didn't change it from Emacs 19.  Perhaps it's not
sensible nowadays.

>>> -  (let ((primary (x-get-selection 'PRIMARY)))
>>> +  (let ((primary (x-get-selection 'PRIMARY 'TEXT)))
> >
> > Would it make sense to have x-get-selection default to 'TEXT instead?

> TEXT can be in any encoding which can make it diffcult.

Ah, yes.

> 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.

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.

> But I think the application should not offer STRING (which
> implies Latin-1) if the data isn't in latin-1.

Fully agreed.

---
Kenichi Handa
handa <at> m17n.org

Previous Next

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