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

Previous Next

Full log

View this message in rfc822 format

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

> From: Mike FABIAN <mfabian <at> redhat.com>
> Cc: 20906 <at> debbugs.gnu.org
> Date: Mon, 05 Oct 2015 17:05:27 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> さんはかきました:
> 
> >> 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.
> 
> With the Emacs version as distributed on Fedora 22, i.e.:
> 
> $ /usr/bin/emacs --version
> GNU Emacs 24.5.1
> 
> it works fine though. From rxvt-unicode, from firefox and gtk-programs,
> from xterm, everything fine.
> 
> With “GNU Emacs 25.0.50.1” compiled from current git master,
> it does not work.

So I guess the logical next step is to see what is different between
these 2 versions, first wrt what happens in xselect.c.  If we get the
non-ASCII codepoints there instead of the literal \uNNNN strings, then
the difference is probably with how we request the selection data, and
if we get the same strings in 24.5, then the difference is probably in
how we process the data after x_get_window_property returns it.

Could you look into this, please?

Thanks.

Previous Next

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