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

Previous Next

Package: emacs;

Reported by: Kaloian Doganov <kaloian <at> gnu.org>

Date: Thu, 5 Aug 2010 15:32:01 UTC

Severity: normal

Merged with 6635

Found in version 24.0.50

Done: Jan Djärv <jan.h.d <at> swipnet.se>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Kenichi Handa <handa <at> m17n.org>
To: $(D*^(Bt$(D+5(Bp$(D+!(Bn N$(D+5(Bmec <stepnem <at> gmail.com>
Cc: kaloian <at> gnu.org, jan.h.d <at> swipnet.se, 6802 <at> debbugs.gnu.org
Subject: bug#6802: 24.0.50; Yanking non-ASCII text from other X application leads to	unicode	escapes
Date: Fri, 29 Oct 2010 11:18:52 +0900
In article <87fwvq4ix4.fsf <at> gmail.com>, $(D*^(Bt$(D+5(Bp$(D+!(Bn N$(D+5(Bmec <stepnem <at> gmail.com> writes:
>>> 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?

As I have been using my private version of
mouse-yank-primary (calling (x-selection-value-internal nil)
instead of (x-get-selection ...)), I didn't notice that this
problem has not yet been solved.  :-(

I wrote:

> It seems that overhaul and re-design is necessary.

but I don't have a time to work on it at the moment.  Any
volunteer?

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




This bug report was last modified 13 years and 233 days ago.

Previous Next


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