* bug#20906: 25.0.50; Pasting unicode from external applications with mouse wheel on Unix @ 2015-06-26 20:35 Boris Kheyfets 2015-06-26 21:37 ` Kaushal 2015-10-03 13:15 ` bug#20906: 25.0.50; Mike FABIAN 0 siblings, 2 replies; 48+ messages in thread From: Boris Kheyfets @ 2015-06-26 20:35 UTC (permalink / raw) To: 20906 [-- 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 --] ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#20906: 25.0.50; Pasting unicode from external applications with mouse wheel on Unix 2015-06-26 20:35 bug#20906: 25.0.50; Pasting unicode from external applications with mouse wheel on Unix Boris Kheyfets @ 2015-06-26 21:37 ` Kaushal 2015-06-26 21:41 ` Boris Kheyfets 2015-10-03 13:15 ` bug#20906: 25.0.50; Mike FABIAN 1 sibling, 1 reply; 48+ messages in thread From: Kaushal @ 2015-06-26 21:37 UTC (permalink / raw) To: 20906; +Cc: kheyfboris [-- 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 --] ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#20906: 25.0.50; Pasting unicode from external applications with mouse wheel on Unix 2015-06-26 21:37 ` Kaushal @ 2015-06-26 21:41 ` Boris Kheyfets 2015-06-27 7:27 ` Eli Zaretskii 0 siblings, 1 reply; 48+ messages in thread From: Boris Kheyfets @ 2015-06-26 21:41 UTC (permalink / raw) To: Kaushal; +Cc: 20906 [-- 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 --] ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#20906: 25.0.50; Pasting unicode from external applications with mouse wheel on Unix 2015-06-26 21:41 ` Boris Kheyfets @ 2015-06-27 7:27 ` Eli Zaretskii 2015-06-27 7:58 ` Boris Kheyfets 0 siblings, 1 reply; 48+ messages in thread From: Eli Zaretskii @ 2015-06-27 7:27 UTC (permalink / raw) To: Boris Kheyfets; +Cc: 20906, kaushal.modi > 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#20906: 25.0.50; Pasting unicode from external applications with mouse wheel on Unix 2015-06-27 7:27 ` Eli Zaretskii @ 2015-06-27 7:58 ` Boris Kheyfets 2015-06-27 8:12 ` Eli Zaretskii 0 siblings, 1 reply; 48+ messages in thread From: Boris Kheyfets @ 2015-06-27 7:58 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 20906, Kaushal Modi [-- 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 --] ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#20906: 25.0.50; Pasting unicode from external applications with mouse wheel on Unix 2015-06-27 7:58 ` Boris Kheyfets @ 2015-06-27 8:12 ` Eli Zaretskii [not found] ` <CADVzOS83fAf1na7ThotyD3mGOJak-U=ZayhGd=cC3=xT2JZuKQ@mail.gmail.com> 0 siblings, 1 reply; 48+ messages in thread From: Eli Zaretskii @ 2015-06-27 8:12 UTC (permalink / raw) To: Boris Kheyfets; +Cc: 20906, kaushal.modi > 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 ="? ^ permalink raw reply [flat|nested] 48+ messages in thread
[parent not found: <CADVzOS83fAf1na7ThotyD3mGOJak-U=ZayhGd=cC3=xT2JZuKQ@mail.gmail.com>]
* bug#20906: 25.0.50; Pasting unicode from external applications with mouse wheel on Unix [not found] ` <CADVzOS83fAf1na7ThotyD3mGOJak-U=ZayhGd=cC3=xT2JZuKQ@mail.gmail.com> @ 2015-06-27 8:33 ` Eli Zaretskii 2015-06-27 8:34 ` Eli Zaretskii 1 sibling, 0 replies; 48+ messages in thread From: Eli Zaretskii @ 2015-06-27 8:33 UTC (permalink / raw) To: Boris Kheyfets; +Cc: 20906, kaushal.modi > 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? ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#20906: 25.0.50; Pasting unicode from external applications with mouse wheel on Unix [not found] ` <CADVzOS83fAf1na7ThotyD3mGOJak-U=ZayhGd=cC3=xT2JZuKQ@mail.gmail.com> 2015-06-27 8:33 ` Eli Zaretskii @ 2015-06-27 8:34 ` Eli Zaretskii 2015-06-27 10:02 ` Boris Kheyfets 1 sibling, 1 reply; 48+ messages in thread From: Eli Zaretskii @ 2015-06-27 8:34 UTC (permalink / raw) To: Boris Kheyfets; +Cc: 20906, kaushal.modi > 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.) ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#20906: 25.0.50; Pasting unicode from external applications with mouse wheel on Unix 2015-06-27 8:34 ` Eli Zaretskii @ 2015-06-27 10:02 ` Boris Kheyfets 2015-06-27 11:44 ` Eli Zaretskii 0 siblings, 1 reply; 48+ messages in thread From: Boris Kheyfets @ 2015-06-27 10:02 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 20906, Kaushal Modi [-- 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 --] ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#20906: 25.0.50; Pasting unicode from external applications with mouse wheel on Unix 2015-06-27 10:02 ` Boris Kheyfets @ 2015-06-27 11:44 ` Eli Zaretskii 0 siblings, 0 replies; 48+ messages in thread From: Eli Zaretskii @ 2015-06-27 11:44 UTC (permalink / raw) To: Boris Kheyfets; +Cc: 20906, kaushal.modi > 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#20906: 25.0.50; 2015-06-26 20:35 bug#20906: 25.0.50; Pasting unicode from external applications with mouse wheel on Unix Boris Kheyfets 2015-06-26 21:37 ` Kaushal @ 2015-10-03 13:15 ` Mike FABIAN 2015-10-03 14:00 ` Eli Zaretskii 1 sibling, 1 reply; 48+ messages in thread From: Mike FABIAN @ 2015-10-03 13:15 UTC (permalink / raw) To: 20906 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#20906: 25.0.50; 2015-10-03 13:15 ` bug#20906: 25.0.50; Mike FABIAN @ 2015-10-03 14:00 ` Eli Zaretskii 2015-10-05 4:34 ` Mike FABIAN 0 siblings, 1 reply; 48+ messages in thread From: Eli Zaretskii @ 2015-10-03 14:00 UTC (permalink / raw) To: Mike FABIAN; +Cc: 20906 > 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? ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#20906: 25.0.50; 2015-10-03 14:00 ` Eli Zaretskii @ 2015-10-05 4:34 ` Mike FABIAN 2015-10-05 6:21 ` Eli Zaretskii 0 siblings, 1 reply; 48+ messages in thread From: Mike FABIAN @ 2015-10-05 4:34 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 20906 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> 睡眠不足はいい仕事の敵だ。 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#20906: 25.0.50; 2015-10-05 4:34 ` Mike FABIAN @ 2015-10-05 6:21 ` Eli Zaretskii 2015-10-05 6:30 ` Mike FABIAN 0 siblings, 1 reply; 48+ messages in thread From: Eli Zaretskii @ 2015-10-05 6:21 UTC (permalink / raw) To: Mike FABIAN; +Cc: 20906 > 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? ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#20906: 25.0.50; 2015-10-05 6:21 ` Eli Zaretskii @ 2015-10-05 6:30 ` Mike FABIAN 2015-10-05 7:06 ` Eli Zaretskii 0 siblings, 1 reply; 48+ messages in thread From: Mike FABIAN @ 2015-10-05 6:30 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 20906 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> 睡眠不足はいい仕事の敵だ。 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#20906: 25.0.50; 2015-10-05 6:30 ` Mike FABIAN @ 2015-10-05 7:06 ` Eli Zaretskii 2015-10-05 10:07 ` Mike FABIAN 0 siblings, 1 reply; 48+ messages in thread From: Eli Zaretskii @ 2015-10-05 7:06 UTC (permalink / raw) To: Mike FABIAN; +Cc: 20906 > 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? ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#20906: 25.0.50; 2015-10-05 7:06 ` Eli Zaretskii @ 2015-10-05 10:07 ` Mike FABIAN 2015-10-05 10:29 ` Eli Zaretskii 0 siblings, 1 reply; 48+ messages in thread From: Mike FABIAN @ 2015-10-05 10:07 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 20906 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 睡眠不足はいい仕事の敵だ。 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#20906: 25.0.50; 2015-10-05 10:07 ` Mike FABIAN @ 2015-10-05 10:29 ` Eli Zaretskii 2015-10-05 11:20 ` Mike FABIAN 0 siblings, 1 reply; 48+ messages in thread From: Eli Zaretskii @ 2015-10-05 10:29 UTC (permalink / raw) To: Mike FABIAN; +Cc: 20906 > 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? ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#20906: 25.0.50; 2015-10-05 10:29 ` Eli Zaretskii @ 2015-10-05 11:20 ` Mike FABIAN 2015-10-05 11:39 ` Eli Zaretskii 0 siblings, 1 reply; 48+ messages in thread From: Mike FABIAN @ 2015-10-05 11:20 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 20906 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 睡眠不足はいい仕事の敵だ。 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#20906: 25.0.50; 2015-10-05 11:20 ` Mike FABIAN @ 2015-10-05 11:39 ` Eli Zaretskii 2015-10-05 12:04 ` Andreas Schwab ` (3 more replies) 0 siblings, 4 replies; 48+ messages in thread From: Eli Zaretskii @ 2015-10-05 11:39 UTC (permalink / raw) To: Mike FABIAN; +Cc: 20906 > 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? ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#20906: 25.0.50; 2015-10-05 11:39 ` Eli Zaretskii @ 2015-10-05 12:04 ` Andreas Schwab 2015-10-05 12:30 ` Eli Zaretskii 2015-10-05 14:24 ` Mike FABIAN 2015-10-05 14:55 ` Mike FABIAN ` (2 subsequent siblings) 3 siblings, 2 replies; 48+ messages in thread From: Andreas Schwab @ 2015-10-05 12:04 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 20906, Mike FABIAN 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." ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#20906: 25.0.50; 2015-10-05 12:04 ` Andreas Schwab @ 2015-10-05 12:30 ` Eli Zaretskii 2015-10-05 15:08 ` Mike FABIAN 2015-10-05 14:24 ` Mike FABIAN 1 sibling, 1 reply; 48+ messages in thread From: Eli Zaretskii @ 2015-10-05 12:30 UTC (permalink / raw) To: Andreas Schwab; +Cc: 20906, mfabian > 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#20906: 25.0.50; 2015-10-05 12:30 ` Eli Zaretskii @ 2015-10-05 15:08 ` Mike FABIAN 2015-10-05 17:06 ` Eli Zaretskii 0 siblings, 1 reply; 48+ messages in thread From: Mike FABIAN @ 2015-10-05 15:08 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Andreas Schwab, 20906 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> 睡眠不足はいい仕事の敵だ。 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#20906: 25.0.50; 2015-10-05 15:08 ` Mike FABIAN @ 2015-10-05 17:06 ` Eli Zaretskii 2015-10-06 6:30 ` Mike FABIAN 0 siblings, 1 reply; 48+ messages in thread From: Eli Zaretskii @ 2015-10-05 17:06 UTC (permalink / raw) To: Mike FABIAN; +Cc: schwab, 20906 > 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? ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#20906: 25.0.50; 2015-10-05 17:06 ` Eli Zaretskii @ 2015-10-06 6:30 ` Mike FABIAN 2015-10-06 16:29 ` Eli Zaretskii 0 siblings, 1 reply; 48+ messages in thread From: Mike FABIAN @ 2015-10-06 6:30 UTC (permalink / raw) To: Eli Zaretskii; +Cc: schwab, 20906 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> 睡眠不足はいい仕事の敵だ。 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#20906: 25.0.50; 2015-10-06 6:30 ` Mike FABIAN @ 2015-10-06 16:29 ` Eli Zaretskii 2015-10-06 19:44 ` Mike FABIAN 2015-10-08 13:15 ` Mike FABIAN 0 siblings, 2 replies; 48+ messages in thread From: Eli Zaretskii @ 2015-10-06 16:29 UTC (permalink / raw) To: Mike FABIAN; +Cc: schwab, 20906 > 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? ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#20906: 25.0.50; 2015-10-06 16:29 ` Eli Zaretskii @ 2015-10-06 19:44 ` Mike FABIAN 2015-10-07 6:35 ` Mike FABIAN 2015-10-08 13:15 ` Mike FABIAN 1 sibling, 1 reply; 48+ messages in thread From: Mike FABIAN @ 2015-10-06 19:44 UTC (permalink / raw) To: Eli Zaretskii; +Cc: schwab, 20906 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> 睡眠不足はいい仕事の敵だ。 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#20906: 25.0.50; 2015-10-06 19:44 ` Mike FABIAN @ 2015-10-07 6:35 ` Mike FABIAN 2015-10-07 15:33 ` Eli Zaretskii 0 siblings, 1 reply; 48+ messages in thread From: Mike FABIAN @ 2015-10-07 6:35 UTC (permalink / raw) To: Eli Zaretskii; +Cc: schwab, 20906 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> 睡眠不足はいい仕事の敵だ。 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#20906: 25.0.50; 2015-10-07 6:35 ` Mike FABIAN @ 2015-10-07 15:33 ` Eli Zaretskii 2015-10-08 8:10 ` Mike FABIAN 0 siblings, 1 reply; 48+ messages in thread From: Eli Zaretskii @ 2015-10-07 15:33 UTC (permalink / raw) To: Mike FABIAN; +Cc: schwab, 20906 > 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#20906: 25.0.50; 2015-10-07 15:33 ` Eli Zaretskii @ 2015-10-08 8:10 ` Mike FABIAN 0 siblings, 0 replies; 48+ messages in thread From: Mike FABIAN @ 2015-10-08 8:10 UTC (permalink / raw) To: Eli Zaretskii; +Cc: schwab, 20906 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> 睡眠不足はいい仕事の敵だ。 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#20906: 25.0.50; 2015-10-06 16:29 ` Eli Zaretskii 2015-10-06 19:44 ` Mike FABIAN @ 2015-10-08 13:15 ` Mike FABIAN 2015-10-08 13:25 ` Mike FABIAN 2015-10-08 14:02 ` Andreas Schwab 1 sibling, 2 replies; 48+ messages in thread From: Mike FABIAN @ 2015-10-08 13:15 UTC (permalink / raw) To: Eli Zaretskii; +Cc: schwab, 20906 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> 睡眠不足はいい仕事の敵だ。 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#20906: 25.0.50; 2015-10-08 13:15 ` Mike FABIAN @ 2015-10-08 13:25 ` Mike FABIAN 2015-10-08 14:02 ` Andreas Schwab 1 sibling, 0 replies; 48+ messages in thread From: Mike FABIAN @ 2015-10-08 13:25 UTC (permalink / raw) To: Eli Zaretskii; +Cc: schwab, 20906 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> 睡眠不足はいい仕事の敵だ。 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#20906: 25.0.50; 2015-10-08 13:15 ` Mike FABIAN 2015-10-08 13:25 ` Mike FABIAN @ 2015-10-08 14:02 ` Andreas Schwab 2015-10-08 14:58 ` Eli Zaretskii 1 sibling, 1 reply; 48+ messages in thread From: Andreas Schwab @ 2015-10-08 14:02 UTC (permalink / raw) To: Mike FABIAN; +Cc: 20906, monnier 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." ^ permalink raw reply related [flat|nested] 48+ messages in thread
* bug#20906: 25.0.50; 2015-10-08 14:02 ` Andreas Schwab @ 2015-10-08 14:58 ` Eli Zaretskii 2015-10-08 15:08 ` Andreas Schwab 0 siblings, 1 reply; 48+ messages in thread From: Eli Zaretskii @ 2015-10-08 14:58 UTC (permalink / raw) To: Andreas Schwab; +Cc: 20906, monnier, mfabian > 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? ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#20906: 25.0.50; 2015-10-08 14:58 ` Eli Zaretskii @ 2015-10-08 15:08 ` Andreas Schwab 2015-10-08 15:15 ` Eli Zaretskii 0 siblings, 1 reply; 48+ messages in thread From: Andreas Schwab @ 2015-10-08 15:08 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 20906, monnier, mfabian 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." ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#20906: 25.0.50; 2015-10-08 15:08 ` Andreas Schwab @ 2015-10-08 15:15 ` Eli Zaretskii 2015-10-08 15:33 ` Andreas Schwab 0 siblings, 1 reply; 48+ messages in thread From: Eli Zaretskii @ 2015-10-08 15:15 UTC (permalink / raw) To: Andreas Schwab; +Cc: 20906, monnier, mfabian > 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? ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#20906: 25.0.50; 2015-10-08 15:15 ` Eli Zaretskii @ 2015-10-08 15:33 ` Andreas Schwab 2015-10-08 15:42 ` Eli Zaretskii 0 siblings, 1 reply; 48+ messages in thread From: Andreas Schwab @ 2015-10-08 15:33 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 20906, monnier, mfabian 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." ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#20906: 25.0.50; 2015-10-08 15:33 ` Andreas Schwab @ 2015-10-08 15:42 ` Eli Zaretskii 2015-10-08 16:56 ` Mike FABIAN 0 siblings, 1 reply; 48+ messages in thread From: Eli Zaretskii @ 2015-10-08 15:42 UTC (permalink / raw) To: Andreas Schwab; +Cc: 20906, monnier, mfabian > 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? ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#20906: 25.0.50; 2015-10-08 15:42 ` Eli Zaretskii @ 2015-10-08 16:56 ` Mike FABIAN 2015-10-09 15:34 ` Mike FABIAN 0 siblings, 1 reply; 48+ messages in thread From: Mike FABIAN @ 2015-10-08 16:56 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Andreas Schwab, 20906, monnier 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 睡眠不足はいい仕事の敵だ。 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#20906: 25.0.50; 2015-10-08 16:56 ` Mike FABIAN @ 2015-10-09 15:34 ` Mike FABIAN 2015-10-12 8:39 ` Andreas Schwab 0 siblings, 1 reply; 48+ messages in thread From: Mike FABIAN @ 2015-10-09 15:34 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Andreas Schwab, 20906, monnier 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> 睡眠不足はいい仕事の敵だ。 ^ permalink raw reply related [flat|nested] 48+ messages in thread
* bug#20906: 25.0.50; 2015-10-09 15:34 ` Mike FABIAN @ 2015-10-12 8:39 ` Andreas Schwab 2015-10-12 12:20 ` Mike FABIAN 0 siblings, 1 reply; 48+ messages in thread From: Andreas Schwab @ 2015-10-12 8:39 UTC (permalink / raw) To: Mike FABIAN; +Cc: 20906-done, monnier 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." ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#20906: 25.0.50; 2015-10-12 8:39 ` Andreas Schwab @ 2015-10-12 12:20 ` Mike FABIAN 2015-10-12 15:56 ` Eli Zaretskii 0 siblings, 1 reply; 48+ messages in thread From: Mike FABIAN @ 2015-10-12 12:20 UTC (permalink / raw) To: Andreas Schwab; +Cc: 20906-done, monnier 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> 睡眠不足はいい仕事の敵だ。 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#20906: 25.0.50; 2015-10-12 12:20 ` Mike FABIAN @ 2015-10-12 15:56 ` Eli Zaretskii 0 siblings, 0 replies; 48+ messages in thread From: Eli Zaretskii @ 2015-10-12 15:56 UTC (permalink / raw) To: Mike FABIAN; +Cc: schwab, 20906, monnier > 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#20906: 25.0.50; 2015-10-05 12:04 ` Andreas Schwab 2015-10-05 12:30 ` Eli Zaretskii @ 2015-10-05 14:24 ` Mike FABIAN 1 sibling, 0 replies; 48+ messages in thread From: Mike FABIAN @ 2015-10-05 14:24 UTC (permalink / raw) To: Andreas Schwab; +Cc: 20906 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 睡眠不足はいい仕事の敵だ。 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#20906: 25.0.50; 2015-10-05 11:39 ` Eli Zaretskii 2015-10-05 12:04 ` Andreas Schwab @ 2015-10-05 14:55 ` Mike FABIAN 2015-10-05 15:01 ` Mike FABIAN 2015-10-05 15:05 ` Mike FABIAN 3 siblings, 0 replies; 48+ messages in thread From: Mike FABIAN @ 2015-10-05 14:55 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 20906 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 睡眠不足はいい仕事の敵だ。 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#20906: 25.0.50; 2015-10-05 11:39 ` Eli Zaretskii 2015-10-05 12:04 ` Andreas Schwab 2015-10-05 14:55 ` Mike FABIAN @ 2015-10-05 15:01 ` Mike FABIAN 2015-10-05 15:05 ` Mike FABIAN 3 siblings, 0 replies; 48+ messages in thread From: Mike FABIAN @ 2015-10-05 15:01 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 20906 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 睡眠不足はいい仕事の敵だ。 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#20906: 25.0.50; 2015-10-05 11:39 ` Eli Zaretskii ` (2 preceding siblings ...) 2015-10-05 15:01 ` Mike FABIAN @ 2015-10-05 15:05 ` Mike FABIAN 2015-10-05 17:05 ` Eli Zaretskii 3 siblings, 1 reply; 48+ messages in thread From: Mike FABIAN @ 2015-10-05 15:05 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 20906 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> 睡眠不足はいい仕事の敵だ。 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#20906: 25.0.50; 2015-10-05 15:05 ` Mike FABIAN @ 2015-10-05 17:05 ` Eli Zaretskii 0 siblings, 0 replies; 48+ messages in thread From: Eli Zaretskii @ 2015-10-05 17:05 UTC (permalink / raw) To: Mike FABIAN; +Cc: 20906 > 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
end of thread, other threads:[~2015-10-12 15:56 UTC | newest] Thread overview: 48+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-06-26 20:35 bug#20906: 25.0.50; Pasting unicode from external applications with mouse wheel on Unix Boris Kheyfets 2015-06-26 21:37 ` Kaushal 2015-06-26 21:41 ` Boris Kheyfets 2015-06-27 7:27 ` Eli Zaretskii 2015-06-27 7:58 ` Boris Kheyfets 2015-06-27 8:12 ` Eli Zaretskii [not found] ` <CADVzOS83fAf1na7ThotyD3mGOJak-U=ZayhGd=cC3=xT2JZuKQ@mail.gmail.com> 2015-06-27 8:33 ` Eli Zaretskii 2015-06-27 8:34 ` Eli Zaretskii 2015-06-27 10:02 ` Boris Kheyfets 2015-06-27 11:44 ` Eli Zaretskii 2015-10-03 13:15 ` bug#20906: 25.0.50; Mike FABIAN 2015-10-03 14:00 ` Eli Zaretskii 2015-10-05 4:34 ` Mike FABIAN 2015-10-05 6:21 ` Eli Zaretskii 2015-10-05 6:30 ` Mike FABIAN 2015-10-05 7:06 ` Eli Zaretskii 2015-10-05 10:07 ` Mike FABIAN 2015-10-05 10:29 ` Eli Zaretskii 2015-10-05 11:20 ` Mike FABIAN 2015-10-05 11:39 ` Eli Zaretskii 2015-10-05 12:04 ` Andreas Schwab 2015-10-05 12:30 ` Eli Zaretskii 2015-10-05 15:08 ` Mike FABIAN 2015-10-05 17:06 ` Eli Zaretskii 2015-10-06 6:30 ` Mike FABIAN 2015-10-06 16:29 ` Eli Zaretskii 2015-10-06 19:44 ` Mike FABIAN 2015-10-07 6:35 ` Mike FABIAN 2015-10-07 15:33 ` Eli Zaretskii 2015-10-08 8:10 ` Mike FABIAN 2015-10-08 13:15 ` Mike FABIAN 2015-10-08 13:25 ` Mike FABIAN 2015-10-08 14:02 ` Andreas Schwab 2015-10-08 14:58 ` Eli Zaretskii 2015-10-08 15:08 ` Andreas Schwab 2015-10-08 15:15 ` Eli Zaretskii 2015-10-08 15:33 ` Andreas Schwab 2015-10-08 15:42 ` Eli Zaretskii 2015-10-08 16:56 ` Mike FABIAN 2015-10-09 15:34 ` Mike FABIAN 2015-10-12 8:39 ` Andreas Schwab 2015-10-12 12:20 ` Mike FABIAN 2015-10-12 15:56 ` Eli Zaretskii 2015-10-05 14:24 ` Mike FABIAN 2015-10-05 14:55 ` Mike FABIAN 2015-10-05 15:01 ` Mike FABIAN 2015-10-05 15:05 ` Mike FABIAN 2015-10-05 17:05 ` Eli Zaretskii
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.