bug#20906: 25.0.50; Pasting unicode from external applications with mouse wheel on Unix

bug#20906: 25.0.50; Pasting unicode from external applications with mouse wheel on Unix

[Boris Kheyfets]

[-- Attachment #1: Type: text/plain, Size: 5950 bytes --]

1. On unix-like OS visit https://en.wikipedia.org/wiki/Paul_Erdős in firefox
2. Copy its link
3. Paste it with mouse wheel. Result: Paul_Erd\u0151s
4. Paste it with M-x clipboard-yank. Result: Paul_Erdős

The bug is confirmed by independent user here:
http://emacs.stackexchange.com/questions/13472/pasting-unicode-from-external-applications-with-mouse-wheel-on-unix?noredirect=1#comment20167_13472



In GNU Emacs 25.0.50.1 (x86_64-pc-linux-gnu, GTK+ Version 3.10.8)
 of 2015-05-19 on lcy01-07
Windowing system distributor `The X.Org Foundation', version 11.0.11501000
System Description:    Ubuntu 14.04.1 LTS

Configured using:
 `configure --build=x86_64-linux-gnu --prefix=/usr
 '--includedir=${prefix}/include' '--mandir=${prefix}/share/man'
 '--infodir=${prefix}/share/info' --sysconfdir=/etc --localstatedir=/var
 '--libdir=${prefix}/lib/x86_64-linux-gnu'
 '--libexecdir=${prefix}/lib/x86_64-linux-gnu' --disable-maintainer-mode
 --disable-dependency-tracking --prefix=/usr --sharedstatedir=/var/lib
 --program-suffix=-snapshot --with-x=yes --with-x-toolkit=gtk3
 'CFLAGS=-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat
 -Werror=format-security' CPPFLAGS=-D_FORTIFY_SOURCE=2
 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro''

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS
NOTIFY LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Text

Minor modes in effect:
  csv-field-index-mode: t
  diff-auto-refine-mode: t
  TeX-PDF-mode: t
  tabbar-mwheel-mode: t
  tabbar-mode: t
  helm-mode: t
  shell-dirtrack-mode: t
  async-bytecomp-package-mode: t
  ido-everywhere: t
  cua-mode: t
  global-auto-revert-mode: t
  global-subword-mode: t
  subword-mode: t
  recentf-mode: t
  global-whitespace-mode: t
  show-paren-mode: t
  delete-selection-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t

Recent messages:
Mark set [2 times]
Undo!
Mark set [2 times]
next-line: End of buffer
Mark set [2 times]
Undo!
Mark set [3 times]
Buffer new<6> modified; Do you want to save? (y or n) n
mwheel-scroll: Beginning of buffer [4 times]
Mark set [3 times]

Load-path shadows:
/usr/share/emacs/site-lisp/rst hides
/usr/share/emacs/25.0.50/lisp/textmodes/rst
/usr/share/emacs/site-lisp/dictionaries-common/ispell hides
/usr/share/emacs/25.0.50/lisp/textmodes/ispell
/usr/share/emacs/site-lisp/dictionaries-common/flyspell hides
/usr/share/emacs/25.0.50/lisp/textmodes/flyspell

Features:
(shadow mail-extr emacsbug message rfc822 mml mml-sec mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mail-utils winner csv-mode sort
jka-compr eieio-opt speedbar sb-image ezimage dframe find-func misearch
multi-isearch vc vc-dispatcher markdown-mode noutline outline server
vc-git diff-mode bk-misis-minor-mode bk-canvas-minor-mode
bk-pentadactyl-mode lib-gnrl rect lib-bk-TeX latex tex-style tex dbus
crm lib-bk-rst rst lib-bk-py python-mode derived info-look flymake cl
cc-cmds cc-engine cc-vars cc-defs lib-bk-org lib-bk-math two-column
lib-bk-gnrl lib-bk-bash buffer-extension iso-transl hippie-exp help-mode
dired+ image-file tabbar ibuffer helm-mode helm-files rx image-dired
tramp tramp-compat tramp-loaddefs trampver shell pcomplete format-spec
dired-x dired-aux ffap thingatpt helm-buffers helm-elscreen helm-tags
helm-bookmark helm-adaptive helm-info bookmark pp helm-locate helm-help
helm-match-plugin helm-grep helm-regexp helm-plugin grep helm-external
helm-net browse-url xml url url-proxy url-privacy url-expand url-methods
url-history url-cookie url-domsuf url-util url-parse auth-source
gnus-util mm-util mail-prsvr password-cache url-vars mailcap helm-utils
dired compile comint ansi-color ring helm easy-mmode cl-macs helm-source
cl-seq eieio-compat eieio byte-opt gv bytecomp byte-compile cconv
eieio-core helm-config helm-easymenu edmacro kmacro async-bytecomp
advice help-fns async helm-aliases ido cua-base sh-script smie
executable autorevert filenotify cap-words superword subword recentf
tree-widget disp-table whitespace cl-extra seq paren delsel cus-edit
cus-start cus-load wid-edit cl-loaddefs pcase cl-lib finder-inf tex-site
info easymenu package epg-config time-date mule-util tooltip eldoc
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list newcomment elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer cl-preloaded nadvice loaddefs button faces cus-face macroexp
files text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote dbusbind gfilenotify
dynamic-setting system-font-setting font-render-setting move-toolbar gtk
x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 449847 30693)
 (symbols 48 44192 0)
 (miscs 40 1965 794)
 (strings 32 100958 16873)
 (string-bytes 1 3239770)
 (vectors 16 44335)
 (vector-slots 8 1564190 208828)
 (floats 8 343 532)
 (intervals 56 7067 69)
 (buffers 976 24)
 (heap 1024 71572 2841))

[-- Attachment #2: Type: text/html, Size: 6683 bytes --]

bug#20906: 25.0.50; Pasting unicode from external applications with mouse wheel on Unix

[Kaushal]

[-- Attachment #1: Type: text/plain, Size: 111 bytes --]

Could this be related to this debbugs:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=19310 ?


--
Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 517 bytes --]

bug#20906: 25.0.50; Pasting unicode from external applications with mouse wheel on Unix

[Boris Kheyfets]

[-- Attachment #1: Type: text/plain, Size: 229 bytes --]

Yep, sounds the same.

Boris.

On Sat, Jun 27, 2015 at 12:37 AM, Kaushal <kaushal.modi@gmail.com> wrote:

> Could this be related to this debbugs:
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=19310 ?
>
>
> --
> Kaushal Modi
>

[-- Attachment #2: Type: text/html, Size: 1082 bytes --]

bug#20906: 25.0.50; Pasting unicode from external applications with mouse wheel on Unix

[Eli Zaretskii]

> From: Boris Kheyfets <kheyfboris@gmail.com>
> Date: Sat, 27 Jun 2015 00:41:40 +0300
> Cc: 20906@debbugs.gnu.org
> 
> Yep, sounds the same.

Is this in a GUI session or in a text-mode (-nw) session?

I don't think Emacs shows \uNNNN escapes in GUI sessions.

bug#20906: 25.0.50; Pasting unicode from external applications with mouse wheel on Unix

[Boris Kheyfets]

[-- Attachment #1: Type: text/plain, Size: 427 bytes --]

It is a GUI session: emacs 25.0.50 does shows \uNNNN escapes in GUI session.



On Sat, Jun 27, 2015 at 10:27 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Boris Kheyfets <kheyfboris@gmail.com>
> > Date: Sat, 27 Jun 2015 00:41:40 +0300
> > Cc: 20906@debbugs.gnu.org
> >
> > Yep, sounds the same.
>
> Is this in a GUI session or in a text-mode (-nw) session?
>
> I don't think Emacs shows \uNNNN escapes in GUI sessions.
>

[-- Attachment #2: Type: text/html, Size: 942 bytes --]

bug#20906: 25.0.50; Pasting unicode from external applications with mouse wheel on Unix

[Eli Zaretskii]

> From: Boris Kheyfets <kheyfboris@gmail.com>
> Date: Sat, 27 Jun 2015 10:58:55 +0300
> Cc: Kaushal Modi <kaushal.modi@gmail.com>, 20906@debbugs.gnu.org
> 
> emacs 25.0.50 does shows \uNNNN escapes in GUI session.

Do you see such an escape in "emacs -Q" if you type

  C-x 8 RET 0151 RET

?  If so, what does Emacs display in a *Help* buffer if you go to that
escape and type "C-u C-x ="?

bug#20906: 25.0.50; Pasting unicode from external applications with mouse wheel on Unix

[Eli Zaretskii]

> From: Boris Kheyfets <kheyfboris@gmail.com>
> Date: Sat, 27 Jun 2015 11:30:12 +0300
> 
> Nope -- with "C-x 8 RET 0151 RET" I see the correct unicode glyph: ő

Then what does "C-u C-x =" say about that \uNNNN escape in your
original recipe?

bug#20906: 25.0.50; Pasting unicode from external applications with mouse wheel on Unix

[Eli Zaretskii]

> From: Boris Kheyfets <kheyfboris@gmail.com>
> Date: Sat, 27 Jun 2015 11:30:12 +0300
> 
> Nope -- with "C-x 8 RET 0151 RET" I see the correct unicode glyph: ő

Then what does "C-u C-x =" say about that \uNNNN escape in your
original recipe?  Is it a single character (i.e., does C-f move across
the entire sequence in one go), or is it a sequence of several literal
characters, \ u 0 5 0 1?

(And please keep the bug address on the CC list when you reply.)

bug#20906: 25.0.50; Pasting unicode from external applications with mouse wheel on Unix

[Boris Kheyfets]

[-- Attachment #1.1: Type: text/plain, Size: 622 bytes --]

C-f moves one char at a time: \ u 0 5 0 1


​

On Sat, Jun 27, 2015 at 11:34 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Boris Kheyfets <kheyfboris@gmail.com>
> > Date: Sat, 27 Jun 2015 11:30:12 +0300
> >
> > Nope -- with "C-x 8 RET 0151 RET" I see the correct unicode glyph: ő
>
> Then what does "C-u C-x =" say about that \uNNNN escape in your
> original recipe?  Is it a single character (i.e., does C-f move across
> the entire sequence in one go), or is it a sequence of several literal
> characters, \ u 0 5 0 1?
>
> (And please keep the bug address on the CC list when you reply.)
>
>

[-- Attachment #1.2: Type: text/html, Size: 1214 bytes --]

[-- Attachment #2: out.gif --]
[-- Type: image/gif, Size: 65530 bytes --]

bug#20906: 25.0.50; Pasting unicode from external applications with mouse wheel on Unix

[Eli Zaretskii]

> From: Boris Kheyfets <kheyfboris@gmail.com>
> Date: Sat, 27 Jun 2015 13:02:59 +0300
> Cc: 20906@debbugs.gnu.org, Kaushal Modi <kaushal.modi@gmail.com>
> 
> C-f moves one char at a time: \ u 0 5 0 1

So we don't insert a character there, we insert a string.

Crystal ball says that this is related to the fact that the URL
includes a UTF-8 sequence for the offending character.

I guess this is for someone with access to such a system to debug.

bug#20906: 25.0.50;

[Mike FABIAN]

I see the same with Emacs 25.0.50.1 when pasting from rxvt-unicode
or firefox into Emacs using the mouse button. The pasted text does
not have to come from an URL, it happens with any text pasted
from firefox.

bug#20906: 25.0.50;

[Eli Zaretskii]

> From: Mike FABIAN <mfabian@redhat.com>
> Date: Sat, 03 Oct 2015 15:15:54 +0200
> 
> I see the same with Emacs 25.0.50.1 when pasting from rxvt-unicode
> or firefox into Emacs using the mouse button. The pasted text does
> not have to come from an URL, it happens with any text pasted
> from firefox.

What is your value of selection-coding-system?

bug#20906: 25.0.50;

[Mike FABIAN]

Eli Zaretskii <eliz@gnu.org> さんはかきました:

>> From: Mike FABIAN <mfabian@redhat.com>
>> Date: Sat, 03 Oct 2015 15:15:54 +0200
>> 
>> I see the same with Emacs 25.0.50.1 when pasting from rxvt-unicode
>> or firefox into Emacs using the mouse button. The pasted text does
>> not have to come from an URL, it happens with any text pasted
>> from firefox.
>
> What is your value of selection-coding-system?

nil

-- 
Mike FABIAN <mfabian@redhat.com>
睡眠不足はいい仕事の敵だ。

bug#20906: 25.0.50;

[Eli Zaretskii]

> From: Mike FABIAN <mfabian@redhat.com>
> Cc: 20906@debbugs.gnu.org
> Date: Mon, 05 Oct 2015 06:34:12 +0200
> 
> Eli Zaretskii <eliz@gnu.org> さんはかきました:
> 
> >> From: Mike FABIAN <mfabian@redhat.com>
> >> Date: Sat, 03 Oct 2015 15:15:54 +0200
> >> 
> >> I see the same with Emacs 25.0.50.1 when pasting from rxvt-unicode
> >> or firefox into Emacs using the mouse button. The pasted text does
> >> not have to come from an URL, it happens with any text pasted
> >> from firefox.
> >
> > What is your value of selection-coding-system?
> 
> nil

Does it help to set it to utf-8 or compound-text-with-extensions?

bug#20906: 25.0.50;

[Mike FABIAN]

Eli Zaretskii <eliz@gnu.org> さんはかきました:

Eli> What is your value of selection-coding-system?

Mike> nil

Eli> Does it help to set it to utf-8 or compound-text-with-extensions?

Unfortunately not, I had already tried that.

-- 
Mike FABIAN <mfabian@redhat.com>
睡眠不足はいい仕事の敵だ。

bug#20906: 25.0.50;

[Eli Zaretskii]

> From: Mike FABIAN <mfabian@redhat.com>
> Cc: 20906@debbugs.gnu.org
> Date: Mon, 05 Oct 2015 08:30:12 +0200
> 
> Eli Zaretskii <eliz@gnu.org> さんはかきました:
> 
> Eli> What is your value of selection-coding-system?
> 
> Mike> nil
> 
> Eli> Does it help to set it to utf-8 or compound-text-with-extensions?
> 
> Unfortunately not, I had already tried that.

The only way to debug this is to track the data we receive from the X
selection in xselect.c all the way to mouse-yank-primary, and see
what's going on there.  Can you do that?

bug#20906: 25.0.50;

[Mike FABIAN]

Eli Zaretskii <eliz@gnu.org> さんはかきました:

Eli> The only way to debug this is to track the data we receive from the X
Eli> selection in xselect.c all the way to mouse-yank-primary, and see
Eli> what's going on there.  Can you do that?

In xselect.c near line 1473, there is:

    static Lisp_Object
    x_get_window_property_as_lisp_data (struct x_display_info *dpyinfo,
                                        Window window, Atom property,
                                        Lisp_Object target_type,
                                        Atom selection_atom)
    {
      Atom actual_type;
      int actual_format;
      unsigned long actual_size;
      unsigned char *data = 0;
      ptrdiff_t bytes = 0;
      Lisp_Object val;
      Display *display = dpyinfo->display;

      TRACE0 ("Reading selection data");

      x_get_window_property (display, window, property, &data, &bytes,
                             &actual_type, &actual_format, &actual_size);

And here I see that “data” contains something like this:

    (gdb) p	data
    $1 = (unsigned char *) 0x1a98cb0 "\\u5b8c\\u4e86"

I.e. it seems to be wrong in in that function in “data” already.

Is this the right way to debugging this? Continue like this?

-- 
Mike FABIAN <mfabian@redhat.com>
☏ Office: +49-69-365051027, internal 8875027
睡眠不足はいい仕事の敵だ。

bug#20906: 25.0.50;

[Eli Zaretskii]

> From: Mike FABIAN <mfabian@redhat.com>
> Cc: 20906@debbugs.gnu.org
> Date: Mon, 05 Oct 2015 12:07:19 +0200
> 
> In xselect.c near line 1473, there is:
> 
>     static Lisp_Object
>     x_get_window_property_as_lisp_data (struct x_display_info *dpyinfo,
>                                         Window window, Atom property,
>                                         Lisp_Object target_type,
>                                         Atom selection_atom)
>     {
>       Atom actual_type;
>       int actual_format;
>       unsigned long actual_size;
>       unsigned char *data = 0;
>       ptrdiff_t bytes = 0;
>       Lisp_Object val;
>       Display *display = dpyinfo->display;
> 
>       TRACE0 ("Reading selection data");
> 
>       x_get_window_property (display, window, property, &data, &bytes,
>                              &actual_type, &actual_format, &actual_size);
> 
> And here I see that “data” contains something like this:
> 
>     (gdb) p	data
>     $1 = (unsigned char *) 0x1a98cb0 "\\u5b8c\\u4e86"
> 
> I.e. it seems to be wrong in in that function in “data” already.

That was my guess.  What is the value of 'property', btw?

> Is this the right way to debugging this? Continue like this?

Could it be that some agent unrelated to Emacs produces these strings?
Maybe the selection owner itself (Firefox, right?)?

Do other X programs work OK with pasting from the primary selection
via the mouse?

bug#20906: 25.0.50;

[Mike FABIAN]

Eli Zaretskii <eliz@gnu.org> さんはかきました:

>> From: Mike FABIAN <mfabian@redhat.com>
>> Cc: 20906@debbugs.gnu.org
>> Date: Mon, 05 Oct 2015 12:07:19 +0200
>> 
>> In xselect.c near line 1473, there is:
>> 
>>     static Lisp_Object
>>     x_get_window_property_as_lisp_data (struct x_display_info *dpyinfo,
>>                                         Window window, Atom property,
>>                                         Lisp_Object target_type,
>>                                         Atom selection_atom)
>>     {
>>       Atom actual_type;
>>       int actual_format;
>>       unsigned long actual_size;
>>       unsigned char *data = 0;
>>       ptrdiff_t bytes = 0;
>>       Lisp_Object val;
>>       Display *display = dpyinfo->display;
>> 
>>       TRACE0 ("Reading selection data");
>> 
>>       x_get_window_property (display, window, property, &data, &bytes,
>>                              &actual_type, &actual_format, &actual_size);
>> 
>> And here I see that “data” contains something like this:
>> 
>>     (gdb) p	data
>>     $1 = (unsigned char *) 0x1a98cb0 "\\u5b8c\\u4e86"
>> 
>> I.e. it seems to be wrong in in that function in “data” already.
>
> That was my guess.  What is the value of 'property', btw?

(gdb) p	property
$2 = 602

>> Is this the right way to debugging this? Continue like this?
>
> 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).

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

-- 
Mike FABIAN <mfabian@redhat.com>
☏ Office: +49-69-365051027, internal 8875027
睡眠不足はいい仕事の敵だ。

bug#20906: 25.0.50;

[Eli Zaretskii]

> From: Mike FABIAN <mfabian@redhat.com>
> Cc: 20906@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?

bug#20906: 25.0.50;

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Mike FABIAN <mfabian@redhat.com>
>> Cc: 20906@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?

IIUC this is a dynamically allocated atom, so this needs to be looked up
with xlsatoms.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

bug#20906: 25.0.50;

[Eli Zaretskii]

> From: Andreas Schwab <schwab@suse.de>
> Cc: Mike FABIAN <mfabian@redhat.com>,  20906@debbugs.gnu.org
> Date: Mon, 05 Oct 2015 14:04:48 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Mike FABIAN <mfabian@redhat.com>
> >> Cc: 20906@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?
> 
> IIUC this is a dynamically allocated atom, so this needs to be looked up
> with xlsatoms.

Thanks.  Does XGetAtomName support those dynamically allocated atoms?
If it does, then turning on tracing in xselect.c should AFAICS show
the name on stderr.

bug#20906: 25.0.50;

[Mike FABIAN]

Andreas Schwab <schwab@suse.de> さんはかきました:

Eli> IIUC this is a dynamically allocated atom, so this needs to be looked up
Eli> with xlsatoms.

$ xlsatoms | grep 602
602     _EMACS_TMP_


-- 
Mike FABIAN <mfabian@redhat.com>
☏ Office: +49-69-365051027, internal 8875027
睡眠不足はいい仕事の敵だ。

bug#20906: 25.0.50;

[Mike FABIAN]

Eli Zaretskii <eliz@gnu.org> さんはかきました:

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

The first code point where this happens is

    Ā U+0100 LATIN CAPITAL LETTER A WITH MACRON

For

    ÿ U+00FF LATIN SMALL LETTER Y WITH DIAERESIS

and all smaller code points it works.

-- 
Mike FABIAN <mfabian@redhat.com>
☏ Office: +49-69-365051027, internal 8875027
睡眠不足はいい仕事の敵だ。

bug#20906: 25.0.50;

[Mike FABIAN]

Eli Zaretskii <eliz@gnu.org> さんはかきました:

Eli> Does this happen for any characters above u+007F?  If not, at which
Eli> codepoint does this start happening?
Eli>
Eli> Mike> When pasting from xterm, I get only question marks for the non-ASCII
Eli> Mike> characters. Even worse.
Eli>
Eli> Can you look at the original data in xselect.c in that case?  Does it
Eli> already include the question marks?

Yes. There is a literal question mark already in the data.

The first character which is appears as a question mark there is again

    Ā U+0100 LATIN CAPITAL LETTER A WITH MACRON

for the smaller code points it works.

-- 
Mike FABIAN <mfabian@redhat.com>
☏ Office: +49-69-365051027, internal 8875027
睡眠不足はいい仕事の敵だ。

bug#20906: 25.0.50;

[Mike FABIAN]

Eli Zaretskii <eliz@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.

-- 
Mike FABIAN <mfabian@redhat.com>
睡眠不足はいい仕事の敵だ。

bug#20906: 25.0.50;

[Mike FABIAN]

Eli Zaretskii <eliz@gnu.org> さんはかきました:

>> >> > 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?
>> 
>> IIUC this is a dynamically allocated atom, so this needs to be looked up
>> with xlsatoms.
>
> Thanks.  Does XGetAtomName support those dynamically allocated atoms?
> If it does, then turning on tracing in xselect.c should AFAICS show
> the name on stderr.

With tracing turned on, I see something like this:

Breakpoint 1, x_get_window_property_as_lisp_data (dpyinfo=0x16d9070,
    window=119537791, property=602, target_type=8256, selection_atom=1)
    at xselect.c:1469                                                  
Continuing.
9577: Reading selection data
9577: Read 18 bytes from property _EMACS_TMP_
9577:   Delete property _EMACS_TMP_




-- 
Mike FABIAN <mfabian@redhat.com>
睡眠不足はいい仕事の敵だ。

bug#20906: 25.0.50;

[Eli Zaretskii]

> From: Mike FABIAN <mfabian@redhat.com>
> Cc: 20906@debbugs.gnu.org
> Date: Mon, 05 Oct 2015 17:05:27 +0200
> 
> Eli Zaretskii <eliz@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.

bug#20906: 25.0.50;

[Eli Zaretskii]

> From: Mike FABIAN <mfabian@redhat.com>
> Cc: Andreas Schwab <schwab@suse.de>, 20906@debbugs.gnu.org
> Date: Mon, 05 Oct 2015 17:08:30 +0200
> 
> With tracing turned on, I see something like this:
> 
> Breakpoint 1, x_get_window_property_as_lisp_data (dpyinfo=0x16d9070,
>     window=119537791, property=602, target_type=8256, selection_atom=1)
>     at xselect.c:1469                                                  
> Continuing.
> 9577: Reading selection data
> 9577: Read 18 bytes from property _EMACS_TMP_
> 9577:   Delete property _EMACS_TMP_

Thanks.  Do you see the same in v24.5?

bug#20906: 25.0.50;

[Mike FABIAN]

Eli Zaretskii <eliz@gnu.org> さんはかきました:

>> From: Mike FABIAN <mfabian@redhat.com>
>> Cc: Andreas Schwab <schwab@suse.de>, 20906@debbugs.gnu.org
>> Date: Mon, 05 Oct 2015 17:08:30 +0200
>> 
>> With tracing turned on, I see something like this:
>> 
>> Breakpoint 1, x_get_window_property_as_lisp_data (dpyinfo=0x16d9070,
>>     window=119537791, property=602, target_type=8256, selection_atom=1)
>>     at xselect.c:1469                                                  
>> Continuing.
>> 9577: Reading selection data
>> 9577: Read 18 bytes from property _EMACS_TMP_
>> 9577:   Delete property _EMACS_TMP_
>
> Thanks.  Do you see the same in v24.5?

In v24.5 I see at the same point, i.e. when breaking 
at x_get_window_property_as_lisp_data and then
single stepping until after x_get_window_property:

    (gdb) n
    23750: Reading selection data
    23750: Read 6 bytes from property _EMACS_TMP_
    (gdb) p	data
    $1 = (unsigned char *) 0x145c300 "終了"
    (gdb) p	property
    $2 = 602
    (gdb) c
    Continuing.
    23750:   Delete property _EMACS_TMP_

Here the Japanese text I pasted ("終了") appears just like that
in gdb (running in a terminal in UTF-8 mode, i.e. this is
UTF-8 encoded text).

-- 
Mike FABIAN <mfabian@redhat.com>
睡眠不足はいい仕事の敵だ。

bug#20906: 25.0.50;

[Eli Zaretskii]

> From: Mike FABIAN <mfabian@redhat.com>
> Cc: schwab@suse.de, 20906@debbugs.gnu.org
> Date: Tue, 06 Oct 2015 08:30:11 +0200
> 
> Eli Zaretskii <eliz@gnu.org> さんはかきました:
> 
> >> From: Mike FABIAN <mfabian@redhat.com>
> >> Cc: Andreas Schwab <schwab@suse.de>, 20906@debbugs.gnu.org
> >> Date: Mon, 05 Oct 2015 17:08:30 +0200
> >> 
> >> With tracing turned on, I see something like this:
> >> 
> >> Breakpoint 1, x_get_window_property_as_lisp_data (dpyinfo=0x16d9070,
> >>     window=119537791, property=602, target_type=8256, selection_atom=1)
> >>     at xselect.c:1469                                                  
> >> Continuing.
> >> 9577: Reading selection data
> >> 9577: Read 18 bytes from property _EMACS_TMP_
> >> 9577:   Delete property _EMACS_TMP_
> >
> > Thanks.  Do you see the same in v24.5?
> 
> In v24.5 I see at the same point, i.e. when breaking 
> at x_get_window_property_as_lisp_data and then
> single stepping until after x_get_window_property:
> 
>     (gdb) n
>     23750: Reading selection data
>     23750: Read 6 bytes from property _EMACS_TMP_
>     (gdb) p	data
>     $1 = (unsigned char *) 0x145c300 "終了"
>     (gdb) p	property
>     $2 = 602
>     (gdb) c
>     Continuing.
>     23750:   Delete property _EMACS_TMP_
> 
> Here the Japanese text I pasted ("終了") appears just like that
> in gdb (running in a terminal in UTF-8 mode, i.e. this is
> UTF-8 encoded text).

If the data we receive is different, I guess the only explanation
could be that we request it in some different way?

bug#20906: 25.0.50;

[Mike FABIAN]

Eli Zaretskii <eliz@gnu.org> さんはかきました:

>> Here the Japanese text I pasted ("終了") appears just like that
>> in gdb (running in a terminal in UTF-8 mode, i.e. this is
>> UTF-8 encoded text).
>
> If the data we receive is different, I guess the only explanation
> could be that we request it in some different way?

I am still searching ...

-- 
Mike FABIAN <mfabian@redhat.com>
睡眠不足はいい仕事の敵だ。

bug#20906: 25.0.50;

[Mike FABIAN]

This is the first bad commit (which is a bit weird because it
does not touch xselect.c):

mfabian@ari:/local/mfabian/src/emacs ((31300be...) %|BISECTING)
$ git bisect bad
31300bee24ddcfd7dc27e757513d3c176a7fad83 is the first bad commit
commit 31300bee24ddcfd7dc27e757513d3c176a7fad83
Author: Stefan Monnier <monnier@iro.umontreal.ca>
Date:   Wed Oct 1 23:19:32 2014 -0400

    Consolidate management/ownership of selections.
    * lisp/select.el (gui-get-selection-alist): New method.
    (gui-get-selection): Use it.  Rename from x-get-selection.
    (x-get-selection): Define as obsolete alias.
    (x-get-clipboard): Mark obsolete.
    (gui-get-primary-selection): New function.
    (x-get-selection-value): Mark obsolete.
    (gui-own-selection-alist, gui-disown-selection-alist)
    (gui-selection-owner-p-alist): New methods.
    (gui-set-selection): Use them.  Rename from x-set-selection.
    (x-set-selection): Define as obsolete alias.
    (gui--valid-simple-selection-p): Rename from
    x-valid-simple-selection-p.
    * lisp/w32-common-fns.el (gui-own-selection, gui-disown-selection)
    (gui-selection-owner-p, gui-get-selection): Define for w32.
    (w32-get-selection-value): Rename from x-get-selection-value.
    Use the new gui-last-selected-text.
    * lisp/term/x-win.el (x-get-selection-value): Remove.
    (x-clipboard-yank): Declare obsolete.
    (gui-own-selection, gui-disown-selection, gui-get-selection)
    (gui-selection-owner-p): Define for x.
    * lisp/term/w32-win.el (w32-win-suspend-error): Rename from
    x-win-suspend-error.
    * lisp/term/pc-win.el (w16-get-selection-value): Rename from
    x-get-selection-value.
    (w16-selection-owner-p): Rename from x-selection-owner-p.
    (gui-own-selection, gui-disown-selection, gui-get-selection)
    (gui-selection-owner-p): Define for pc.
    (w16--select-text): New function.
    * lisp/term/ns-win.el (gui-own-selection, gui-disown-selection)
    (gui-get-selection, gui-selection-owner-p): Define for ns.
    * lisp/term.el (term-mouse-paste):
    * lisp/mouse.el (mouse-yank-primary): Use gui-get-primary-selection.
    * src/nsselect.m (ns-own-selection-internal, ns-disown-selection-internal):
    Rename from the "x-" prefix.

:040000 040000 27932670cbd5f701fe2fffcd8cdaebe59ef894af 6a0e0cbfbbcbb245d70c43248f3198a11db714dd M   etc
:040000 040000 f8130a7b693bc45dd440cb7ff0bb24070ee1dd6c db44f34aeb6c3089ef337f2f82234624eed00a97 M   lisp
:040000 040000 b39f4708e656cc5a43e41196453af87a491bb7f1 c68d300831f6dc95ca9b51356129e21255f8d9e1 M   src
mfabian@ari:/local/mfabian/src/emacs ((31300be...) %|BISECTING)
$ 


-- 
Mike FABIAN <mfabian@redhat.com>
睡眠不足はいい仕事の敵だ。

bug#20906: 25.0.50;

[Eli Zaretskii]

> From: Mike FABIAN <mfabian@redhat.com>
> Cc: schwab@suse.de, 20906@debbugs.gnu.org
> Date: Wed, 07 Oct 2015 08:35:15 +0200
> 
> This is the first bad commit (which is a bit weird because it
> does not touch xselect.c):
> 
> mfabian@ari:/local/mfabian/src/emacs ((31300be...) %|BISECTING)
> $ git bisect bad
> 31300bee24ddcfd7dc27e757513d3c176a7fad83 is the first bad commit
> commit 31300bee24ddcfd7dc27e757513d3c176a7fad83
> Author: Stefan Monnier <monnier@iro.umontreal.ca>
> Date:   Wed Oct 1 23:19:32 2014 -0400
> 
>     Consolidate management/ownership of selections.

Any idea which part(s) of this are responsible?  I think we'd need
that to make progress towards a solution, since reverting that
changeset is out of the question.

Thanks.

bug#20906: 25.0.50;

[Mike FABIAN]

Eli Zaretskii <eliz@gnu.org> さんはかきました:

>> From: Mike FABIAN <mfabian@redhat.com>
>> Cc: schwab@suse.de, 20906@debbugs.gnu.org
>> Date: Wed, 07 Oct 2015 08:35:15 +0200
>> 
>> This is the first bad commit (which is a bit weird because it
>> does not touch xselect.c):
>> 
>> mfabian@ari:/local/mfabian/src/emacs ((31300be...) %|BISECTING)
>> $ git bisect bad
>> 31300bee24ddcfd7dc27e757513d3c176a7fad83 is the first bad commit
>> commit 31300bee24ddcfd7dc27e757513d3c176a7fad83
>> Author: Stefan Monnier <monnier@iro.umontreal.ca>
>> Date:   Wed Oct 1 23:19:32 2014 -0400
>> 
>>     Consolidate management/ownership of selections.
>
> Any idea which part(s) of this are responsible?  I think we'd need
> that to make progress towards a solution, since reverting that
> changeset is out of the question.

Yes, of course, I am searching ...

-- 
Mike FABIAN <mfabian@redhat.com>
睡眠不足はいい仕事の敵だ。

bug#20906: 25.0.50;

[Mike FABIAN]

Eli Zaretskii <eliz@gnu.org> さんはかきました:

> If the data we receive is different, I guess the only explanation
> could be that we request it in some different way?

Yes, in the old code

   (defun x-get-selection (&optional type data-type)

is called with “'UTF8_STRING” in data-type,
in the new code 

   (defun gui-get-selection (&optional type data-type)

is called with “nil” in data type.

That seems to make the difference, evaluating

    (gui-get-selection 'PRIMARY 'UTF8_STRING)

gets the selection correctly using the new code,  

    (gui-get-selection 'PRIMARY)

produces the problem I am seeing. 

I still now know why this is called differently, looking ...

-- 
Mike FABIAN <mfabian@redhat.com>
睡眠不足はいい仕事の敵だ。

bug#20906: 25.0.50;

[Mike FABIAN]

Mike FABIAN <mfabian@redhat.com> さんはかきました:

> Eli Zaretskii <eliz@gnu.org> さんはかきました:
>
>> If the data we receive is different, I guess the only explanation
>> could be that we request it in some different way?
>
> Yes, in the old code
>
>    (defun x-get-selection (&optional type data-type)
>
> is called with “'UTF8_STRING” in data-type,
> in the new code 
>
>    (defun gui-get-selection (&optional type data-type)
>
> is called with “nil” in data type.
>
> That seems to make the difference, evaluating
>
>     (gui-get-selection 'PRIMARY 'UTF8_STRING)
>
> gets the selection correctly using the new code,  
>
>     (gui-get-selection 'PRIMARY)
>
> produces the problem I am seeing. 
>
> I still now know why this is called differently, looking ...

New edebug backtrace:

  gui-get-selection(PRIMARY)
  gui-get-primary-selection()
  mouse-yank-primary((mouse-2 (#<window 8 on *scratch*> 657 (345 . 219) 916195932 nil 657 (43 . 14) nil (345 . 3) (8 . 15))))
  funcall-interactively(mouse-yank-primary (mouse-2 (#<window 8 on *scratch*> 657 (345 . 219) 916195932 nil 657 (43 . 14) nil (345 . 3) (8 . 15))))
  call-interactively(mouse-yank-primary nil nil)
  command-execute(mouse-yank-primary)

Old edebug backtrace:

  x-get-selection(PRIMARY UTF8_STRING)
  byte-code("\303\b	@\"\303\207" [type request-type text x-get-selection] 3)
  x-selection-value-internal(PRIMARY)
  x-get-selection-value()
  mouse-yank-primary((mouse-2 (#<window 8 on *scratch*> 192 (460 . 305) 916425597 nil 192 (57 . 4) nil (460 . 245) (8 . 15))))
  funcall-interactively(mouse-yank-primary (mouse-2 (#<window 8 on *scratch*> 192 (460 . 305) 916425597 nil 192 (57 . 4) nil (460 . 245) (8 . 15))))
  call-interactively(mouse-yank-primary nil nil)
  command-execute(mouse-yank-primary)

-- 
Mike FABIAN <mfabian@redhat.com>
睡眠不足はいい仕事の敵だ。

bug#20906: 25.0.50;

[Andreas Schwab]

Mike FABIAN <mfabian@redhat.com> writes:

> Eli Zaretskii <eliz@gnu.org> さんはかきました:
>
>> If the data we receive is different, I guess the only explanation
>> could be that we request it in some different way?
>
> Yes, in the old code
>
>    (defun x-get-selection (&optional type data-type)
>
> is called with “'UTF8_STRING” in data-type,
> in the new code 
>
>    (defun gui-get-selection (&optional type data-type)
>
> is called with “nil” in data type.
>
> That seems to make the difference, evaluating
>
>     (gui-get-selection 'PRIMARY 'UTF8_STRING)
>
> gets the selection correctly using the new code,  
>
>     (gui-get-selection 'PRIMARY)
>
> produces the problem I am seeing. 
>
> I still now know why this is called differently, looking ...

This:

diff --git a/lisp/mouse.el b/lisp/mouse.el
index 93bd628..f569ec3 100644
--- a/lisp/mouse.el
+++ b/lisp/mouse.el
@@ -1068,24 +1068,7 @@ regardless of where you click."
     (let (select-active-regions)
       (deactivate-mark)))
   (or mouse-yank-at-point (mouse-set-point click))
-  (let ((primary
-         (if (fboundp 'x-get-selection-value)
-             (if (eq (framep (selected-frame)) 'w32)
-                 ;; MS-Windows emulates PRIMARY in x-get-selection, but not
-                 ;; in x-get-selection-value (the latter only accesses the
-                 ;; clipboard).  So try PRIMARY first, in case they selected
-                 ;; something with the mouse in the current Emacs session.
-                 (or (x-get-selection 'PRIMARY)
-                     (x-get-selection-value))
-               ;; Else MS-DOS or X.
-               ;; On X, x-get-selection-value supports more formats and
-               ;; encodings, so use it in preference to x-get-selection.
-               (or (x-get-selection-value)
-                   (x-get-selection 'PRIMARY)))
-           ;; FIXME: What about xterm-mouse-mode etc.?
-           (x-get-selection 'PRIMARY))))
-    (unless primary
-      (error "No selection is available"))
+  (let ((primary (gui-get-primary-selection)))
     (push-mark (point))
     (insert-for-yank primary)))
 

The comment is there for a reason...

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

bug#20906: 25.0.50;

[Eli Zaretskii]

> From: Andreas Schwab <schwab@suse.de>
> Cc: Eli Zaretskii <eliz@gnu.org>,  20906@debbugs.gnu.org, monnier@iro.umontreal.ca
> Date: Thu, 08 Oct 2015 16:02:05 +0200
> 
> -               ;; On X, x-get-selection-value supports more formats and
> -               ;; encodings, so use it in preference to x-get-selection.
> -               (or (x-get-selection-value)
> -                   (x-get-selection 'PRIMARY)))
> -           ;; FIXME: What about xterm-mouse-mode etc.?
> -           (x-get-selection 'PRIMARY))))
> -    (unless primary
> -      (error "No selection is available"))
> +  (let ((primary (gui-get-primary-selection)))
>      (push-mark (point))
>      (insert-for-yank primary)))
>  
> 
> The comment is there for a reason...

Thanks.

So I guess gui-backend-get-selection on x-win.el should loop over the
possible request types, like x-selection-value-internal did in Emacs
24.5, is that right?

bug#20906: 25.0.50;

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andreas Schwab <schwab@suse.de>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  20906@debbugs.gnu.org, monnier@iro.umontreal.ca
>> Date: Thu, 08 Oct 2015 16:02:05 +0200
>> 
>> -               ;; On X, x-get-selection-value supports more formats and
>> -               ;; encodings, so use it in preference to x-get-selection.
>> -               (or (x-get-selection-value)
>> -                   (x-get-selection 'PRIMARY)))
>> -           ;; FIXME: What about xterm-mouse-mode etc.?
>> -           (x-get-selection 'PRIMARY))))
>> -    (unless primary
>> -      (error "No selection is available"))
>> +  (let ((primary (gui-get-primary-selection)))
>>      (push-mark (point))
>>      (insert-for-yank primary)))
>>  
>> 
>> The comment is there for a reason...
>
> Thanks.
>
> So I guess gui-backend-get-selection on x-win.el should loop over the
> possible request types, like x-selection-value-internal did in Emacs
> 24.5, is that right?

gui--selection-value-internal still does that.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

bug#20906: 25.0.50;

[Eli Zaretskii]

> From: Andreas Schwab <schwab@suse.de>
> Cc: 20906@debbugs.gnu.org,  monnier@iro.umontreal.ca,  mfabian@redhat.com
> Date: Thu, 08 Oct 2015 17:08:20 +0200
> 
> > So I guess gui-backend-get-selection on x-win.el should loop over the
> > possible request types, like x-selection-value-internal did in Emacs
> > 24.5, is that right?
> 
> gui--selection-value-internal still does that.

Right, so gui-get-primary-selection should call that instead of
calling gui-get-selection, I guess?

bug#20906: 25.0.50;

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andreas Schwab <schwab@suse.de>
>> Cc: 20906@debbugs.gnu.org,  monnier@iro.umontreal.ca,  mfabian@redhat.com
>> Date: Thu, 08 Oct 2015 17:08:20 +0200
>> 
>> > So I guess gui-backend-get-selection on x-win.el should loop over the
>> > possible request types, like x-selection-value-internal did in Emacs
>> > 24.5, is that right?
>> 
>> gui--selection-value-internal still does that.
>
> Right, so gui-get-primary-selection should call that instead of
> calling gui-get-selection, I guess?

I suppose so, if it wants to be the successor of x-get-selection-value.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

bug#20906: 25.0.50;

[Eli Zaretskii]

> From: Andreas Schwab <schwab@suse.de>
> Cc: 20906@debbugs.gnu.org,  monnier@iro.umontreal.ca,  mfabian@redhat.com
> Date: Thu, 08 Oct 2015 17:33:55 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Andreas Schwab <schwab@suse.de>
> >> Cc: 20906@debbugs.gnu.org,  monnier@iro.umontreal.ca,  mfabian@redhat.com
> >> Date: Thu, 08 Oct 2015 17:08:20 +0200
> >> 
> >> > So I guess gui-backend-get-selection on x-win.el should loop over the
> >> > possible request types, like x-selection-value-internal did in Emacs
> >> > 24.5, is that right?
> >> 
> >> gui--selection-value-internal still does that.
> >
> > Right, so gui-get-primary-selection should call that instead of
> > calling gui-get-selection, I guess?
> 
> I suppose so, if it wants to be the successor of x-get-selection-value.

Mike, can you try that?  Or do you want me to write a patch for you to
try?

bug#20906: 25.0.50;

[Mike FABIAN]

Eli Zaretskii <eliz@gnu.org> さんはかきました:

>> From: Andreas Schwab <schwab@suse.de>
>> Cc: 20906@debbugs.gnu.org,  monnier@iro.umontreal.ca,  mfabian@redhat.com
>> Date: Thu, 08 Oct 2015 17:33:55 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> From: Andreas Schwab <schwab@suse.de>
>> >> Cc: 20906@debbugs.gnu.org,  monnier@iro.umontreal.ca,  mfabian@redhat.com
>> >> Date: Thu, 08 Oct 2015 17:08:20 +0200
>> >> 
>> >> > So I guess gui-backend-get-selection on x-win.el should loop over the
>> >> > possible request types, like x-selection-value-internal did in Emacs
>> >> > 24.5, is that right?
>> >> 
>> >> gui--selection-value-internal still does that.
>> >
>> > Right, so gui-get-primary-selection should call that instead of
>> > calling gui-get-selection, I guess?
>> 
>> I suppose so, if it wants to be the successor of x-get-selection-value.
>
> Mike, can you try that?  Or do you want me to write a patch for you to
> try?

I can try to write such a patch tomorrow.

-- 
Mike FABIAN <mfabian@redhat.com>
☏ Office: +49-69-365051027, internal 8875027
睡眠不足はいい仕事の敵だ。

bug#20906: 25.0.50;

[Mike FABIAN]

Mike FABIAN <mfabian@redhat.com> さんはかきました:

> Eli Zaretskii <eliz@gnu.org> さんはかきました:
>
>>> From: Andreas Schwab <schwab@suse.de>
>>> Cc: 20906@debbugs.gnu.org,  monnier@iro.umontreal.ca,  mfabian@redhat.com
>>> Date: Thu, 08 Oct 2015 17:33:55 +0200
>>> 
>>> Eli Zaretskii <eliz@gnu.org> writes:
>>> 
>>> >> From: Andreas Schwab <schwab@suse.de>
>>> >> Cc: 20906@debbugs.gnu.org,  monnier@iro.umontreal.ca,  mfabian@redhat.com
>>> >> Date: Thu, 08 Oct 2015 17:08:20 +0200
>>> >> 
>>> >> > So I guess gui-backend-get-selection on x-win.el should loop over the
>>> >> > possible request types, like x-selection-value-internal did in Emacs
>>> >> > 24.5, is that right?
>>> >> 
>>> >> gui--selection-value-internal still does that.
>>> >
>>> > Right, so gui-get-primary-selection should call that instead of
>>> > calling gui-get-selection, I guess?
>>> 
>>> I suppose so, if it wants to be the successor of x-get-selection-value.
>>
>> Mike, can you try that?  Or do you want me to write a patch for you to
>> try?
>
> I can try to write such a patch tomorrow.

This patch according to Andreas’ suggestion does indeed seem to
fix it for me (pasting now always works, from firefox, gtk, xterm, ...):

From 615bf7c7969e79cbdb5a3890ceaed94c84f2111c Mon Sep 17 00:00:00 2001
From: Mike FABIAN <mfabian@redhat.com>
Date: Thu, 8 Oct 2015 15:45:32 +0200
Subject: [PATCH 1/2] In gui-get-primary-selection use
 gui--selection-value-internal (Bug#20906)

* lisp/select.el (gui-get-primary-selection): In gui-get-primary-selection
use gui--selection-value-internal (Bug#20906)
---
 lisp/select.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/select.el b/lisp/select.el
index 74b48d1..2d2ac5f 100644
--- a/lisp/select.el
+++ b/lisp/select.el
@@ -235,7 +235,7 @@ x-get-clipboard
 
 (defun gui-get-primary-selection ()
   "Return the PRIMARY selection, or the best emulation thereof."
-  (or (gui-get-selection 'PRIMARY)
+  (or (gui--selection-value-internal 'PRIMARY)
       (and (fboundp 'w32-get-selection-value)
            (eq (framep (selected-frame)) 'w32)
            ;; MS-Windows emulates PRIMARY in x-get-selection, but only
-- 
2.4.3



-- 
Mike FABIAN <mfabian@redhat.com>
睡眠不足はいい仕事の敵だ。

bug#20906: 25.0.50;

[Andreas Schwab]

Mike FABIAN <mfabian@redhat.com> writes:

> This patch according to Andreas’ suggestion does indeed seem to
> fix it for me (pasting now always works, from firefox, gtk, xterm, ...):
>
>>From 615bf7c7969e79cbdb5a3890ceaed94c84f2111c Mon Sep 17 00:00:00 2001
> From: Mike FABIAN <mfabian@redhat.com>
> Date: Thu, 8 Oct 2015 15:45:32 +0200
> Subject: [PATCH 1/2] In gui-get-primary-selection use
>  gui--selection-value-internal (Bug#20906)

Installed on master.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

bug#20906: 25.0.50;

[Mike FABIAN]

Andreas Schwab <schwab@suse.de> さんはかきました:

> Mike FABIAN <mfabian@redhat.com> writes:
>
>> This patch according to Andreas’ suggestion does indeed seem to
>> fix it for me (pasting now always works, from firefox, gtk, xterm, ...):
>>
>>>From 615bf7c7969e79cbdb5a3890ceaed94c84f2111c Mon Sep 17 00:00:00 2001
>> From: Mike FABIAN <mfabian@redhat.com>
>> Date: Thu, 8 Oct 2015 15:45:32 +0200
>> Subject: [PATCH 1/2] In gui-get-primary-selection use
>>  gui--selection-value-internal (Bug#20906)
>
> Installed on master.

Thank you!

-- 
Mike FABIAN <mfabian@redhat.com>
睡眠不足はいい仕事の敵だ。

bug#20906: 25.0.50;

[Eli Zaretskii]

> From: Mike FABIAN <mfabian@redhat.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, 20906-done@debbugs.gnu.org,
>         monnier@iro.umontreal.ca
> Date: Mon, 12 Oct 2015 14:20:46 +0200
> 
> Andreas Schwab <schwab@suse.de> さんはかきました:
> 
> > Mike FABIAN <mfabian@redhat.com> writes:
> >
> >> This patch according to Andreas’ suggestion does indeed seem to
> >> fix it for me (pasting now always works, from firefox, gtk, xterm, ...):
> >>
> >>>From 615bf7c7969e79cbdb5a3890ceaed94c84f2111c Mon Sep 17 00:00:00 2001
> >> From: Mike FABIAN <mfabian@redhat.com>
> >> Date: Thu, 8 Oct 2015 15:45:32 +0200
> >> Subject: [PATCH 1/2] In gui-get-primary-selection use
> >>  gui--selection-value-internal (Bug#20906)
> >
> > Installed on master.
> 
> Thank you!

And thank you, Mike, for your efforts and perseverance.