GNU bug report logs - #20906
25.0.50; Pasting unicode from external applications with mouse wheel on Unix

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mike FABIAN <mfabian <at> redhat.com>
Cc: 20906 <at> debbugs.gnu.org
Subject: Re: bug#20906: 25.0.50;
Date: Mon, 05 Oct 2015 14:39:09 +0300

> From: Mike FABIAN <mfabian <at> redhat.com>
> Cc: 20906 <at> debbugs.gnu.org
> Date: Mon, 05 Oct 2015 13:20:55 +0200
> 
> > What is the value of 'property', btw?
> 
> (gdb) p	property
> $2 = 602

Can you look in the X headers what that means?  IOW, what is the
symbolic name of this value?

> > Could it be that some agent unrelated to Emacs produces these strings?
> > Maybe the selection owner itself (Firefox, right?)?
> 
> And rxvt-unicode.
> 
> > Do other X programs work OK with pasting from the primary selection
> > via the mouse?
> 
> No.
> 
> Pasting from gedit, gnome-terminal, ... (probably all gtk3 programs)
> behaves the same way as pasting from firefox (Stuff like
> \u6708\u66dc\u65e5 is inserted).

Sounds like a problem unrelated to Emacs directly.

We could, of course, "decode" these escapes "by hand" in select.el.
But it would be better to understand what causes this "translation" in
the first place.

Does this happen for any characters above u+007F?  If not, at which
codepoint does this start happening?

> When pasting from xterm, I get only question marks for the non-ASCII
> characters. Even worse.

Can you look at the original data in xselect.c in that case?  Does it
already include the question marks?

Previous Next

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