More information about the strange clipboard behaviour
Raúl Núñez de Arenas Coronado
A time ago I posted a message about a problem I was having with the
clipboard and Vim 7.2. After updating to 7.3 I checked to see if the
problem had vanished.
I'm using console-only Vim 7.3-3, self compiled, under Ubuntu Linux
10.04 with X Window System.
Here is how I reproduce it:
- I selected and copied the text "David Gómez" from a GMail message
shown in Google Chrome. The problem only happens with that
combination, Google Chrome and Vim.
- From a terminal:
$ xclip -selection primary -o | od -Ax -tx1
000000 44 61 76 69 64 20 47 c3 b3 6d 65 7a
00000c
$ xclip -selection clipboard -o | od -Ax -tx1
000000 44 61 76 69 64 20 47 c3 b3 6d 65 7a
00000c
As you can see, both the primary and the clipboard selections have the
same text, the UTF-8 representation of "David Gómez".
Now, I paste the text into an empty "vim -u NONE", using "+po<ESC>"*p
and the screen shows this:
David Gómez
David Gómez
~
~
...
As you can see the first text is pasted incorrectly, the second,
correctly. Here is the output of ":registers"
--- Registers ---
"* David Gómez
"+ David Gómez
Again, it is shown that the "+" register is coded incorrectly.
After this, I tried to paste the default clipboard (that is, the one
that gets pasted usually with Ctrl-V) in many different applications
without any problem.
As shown by "xclip", both selections have exactly the same text, the
same bytes, but Vim is treating them differently.
Probably the problem is a Google Chrome one, but since only Vim shows
this behaviour I don't know what to think. If somebody could give me
another example of this problem (or reproduce it) I would be happy to
report the problem to the Google people.
Thanks!!
--
Raúl "DervishD" Núñez de Arenas Coronado
Linux Registered User 88736 | http://www.dervishd.net
The revolution will not be televised
Tony Mechelynck
> Hi all :)
>
> A time ago I posted a message about a problem I was having with the
> clipboard and Vim 7.2. After updating to 7.3 I checked to see if the
> problem had vanished.
> I'm using console-only Vim 7.3-3, self compiled, under Ubuntu Linux
> 10.04 with X Window System.
>
> Here is how I reproduce it:
> shown in Google Chrome. The problem only happens with that
> combination, Google Chrome and Vim.
> - From a terminal:
> $ xclip -selection primary -o | od -Ax -tx1
> 000000 44 61 76 69 64 20 47 c3 b3 6d 65 7a
> 00000c
> $ xclip -selection clipboard -o | od -Ax -tx1
> 000000 44 61 76 69 64 20 47 c3 b3 6d 65 7a
> 00000c
>
> As you can see, both the primary and the clipboard selections have the
>
> Now, I paste the text into an empty "vim -u NONE", using "+po<ESC>"*p
> and the screen shows this:
> David G�mez
> ~
> ~
> ...
>
> As you can see the first text is pasted incorrectly, the second,
> correctly. Here is the output of ":registers"
>
> --- Registers ---
> "+ David Gómez
>
> Again, it is shown that the "+" register is coded incorrectly.
>
> After this, I tried to paste the default clipboard (that is, the one
> that gets pasted usually with Ctrl-V) in many different applications
> without any problem.
> As shown by "xclip", both selections have exactly the same text, the
> same bytes, but Vim is treating them differently.
>
> Probably the problem is a Google Chrome one, but since only Vim shows
> this behaviour I don't know what to think. If somebody could give me
> another example of this problem (or reproduce it) I would be happy to
> report the problem to the Google people.
>
> Thanks!!
>
Well, apparently Vim interprets the clipboard contents as Latin1 and the
primary selection as UTF-8. Not sure why.
- What is your system locale? (Warning: it may be different in a program
such as Chrome, launched from a desktop icon, and in console Vim,
launched by bash. Try running ":language" in gvim started with -u NONE
from Alt-F2 or from the "Run Application..." popup).
- What happens if instead of Chrome you use Firefox or Konqueror or...?
- What happens if instead of Console Vim you use gvim?
Best regards,
Tony.
--
This message contains 78% recycled characters.
Yue Wu
> On 23/08/10 14:58, Raúl Núñez de Arenas Coronado wrote:
> > Hi all :)
> >
> > A time ago I posted a message about a problem I was having with the
> > clipboard and Vim 7.2. After updating to 7.3 I checked to see if the
> > problem had vanished.
> > I'm using console-only Vim 7.3-3, self compiled, under Ubuntu Linux
> > 10.04 with X Window System.
> >
> > Here is how I reproduce it:
> > shown in Google Chrome. The problem only happens with that
> > combination, Google Chrome and Vim.
> >
> > and the screen shows this:
> > David Gómez
> > ~
>
> primary selection as UTF-8. Not sure why.
>
> - What is your system locale? (Warning: it may be different in a program
> such as Chrome, launched from a desktop icon, and in console Vim,
> launched by bash. Try running ":language" in gvim started with -u NONE
> from Alt-F2 or from the "Run Application..." popup).
>
> - What happens if instead of Chrome you use Firefox or Konqueror or...?
>
> - What happens if instead of Console Vim you use gvim?
>
I have the same issue with vim on xterm when copying text from opera. After
copied some Chinese string from opera, say,
氢氧化钠
In vim, "*p and "+p give the weired result:
"'
"'
But shift-insert can paste it correctly. I've tried emacs, emacs can paste it
correcly too.
My local is en_US.UTF-8, vim's 'encoding' option is utf-8.
My OS: FreeBSD fbsd.t60.cpu 8.1-STABLE FreeBSD 8.1-STABLE #0: Fri Aug 27
20:10:55 CST 2010 ro...@fbsd.t60.cpu:/usr/obj/usr/src/sys/T60 i386
My vim:
VIM - Vi IMproved 7.2 (2008 Aug 9, compiled Aug 24 2010 00:37:11)
Included patches: 1-6, 8-35, 37-48, 50-70, 73, 75-87, 90-92, 94-100, 102-137, 139-149, 151
-171, 173-190, 192-193, 195-203, 206-211, 213-215, 217-218, 220-232, 234-246, 251-259, 261
-301, 303-319, 321-322, 324-335, 337-351, 353-361, 363, 366-371, 373, 375-376, 378-383, 38
5-387, 389-398, 401-402, 404-411
Compiled by ro...@fbsd.t60.cpu
Big version without GUI. Features included (+) or not (-):
+arabic +autocmd -balloon_eval -browse ++builtin_terms +byte_offset +cindent
+clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments +cryptv
+cscope +cursorshape +dialog_con +diff +digraphs -dnd -ebcdic +emacs_tags +eval +ex_extra
+extra_search +farsi +file_in_path +find_in_path +float +folding -footer +fork()
-gettext -hangul_input +iconv +insert_expand +jumplist +keymap +langmap +libcall
+linebreak +lispindent +listcmds +localmap +menu +mksession +modify_fname +mouse
-mouseshape +mouse_dec -mouse_gpm -mouse_jsbterm +mouse_netterm +mouse_sysmouse
+mouse_xterm +multi_byte +multi_lang -mzscheme -netbeans_intg -osfiletype +path_extra
-perl +postscript +printer -profile -python +quickfix +reltime +rightleft -ruby
+scrollbind +signs +smartindent -sniff +startuptime +statusline -sun_workshop +syntax
+tag_binary +tag_old_static -tag_any_white -tcl +terminfo +termresponse +textobjects
+title -toolbar +user_commands +vertsplit +virtualedit +visual +visualextra +viminfo
+vreplace +wildignore +wildmenu +windows +writebackup +X11 +xfontset -xim +xsmp_interact
+xterm_clipboard -xterm_save
system vimrc file: "$VIM/vimrc"
user vimrc file: "$HOME/.vimrc"
user exrc file: "$HOME/.exrc"
fall-back for $VIM: "/usr/local/share/vim"
Compilation: cc -c -I. -Iproto -DHAVE_CONFIG_H -I/usr/local/include -O2 -pipe -march=pr
escott -fno-strict-aliasing -march=prescott -D_FORTIFY_SOURCE=1
Linking: cc -L/usr/local/lib -o vim -lXt -lm -ltermlib -liconv
--
Regards,
Yue Wu
Key Laboratory of Modern Chinese Medicines
Department of Traditional Chinese Medicine
China Pharmaceutical University
No.24, Tongjia Xiang Street, Nanjing 210009, China
Raúl Núñez de Arenas Coronado
Sorry for the delay in replying!
2010/8/28 Tony Mechelynck <antoine.m...@gmail.com>:
> Well, apparently Vim interprets the clipboard contents as Latin1 and the
> primary selection as UTF-8. Not sure why.
Almost a decade has passed since I last had to program using xlib
directly, and even then I didn't had to deal with the selections, but
if I remember correctly, there were not any way of specifying the
encoding of the clipboard, although I may be wrong.
> - What is your system locale? (Warning: it may be different in a program
> such as Chrome, launched from a desktop icon, and in console Vim, launched
> by bash. Try running ":language" in gvim started with -u NONE from Alt-F2 or
> from the "Run Application..." popup).
I don't have gvim on my system, but my locale is set system-wise, it's
the same for any app, no matter how is it launched. My locale is
en_US.utf8 except for es_ES.UTF8 in some categories (LC_CTYPE,
LC_COLLATE, LC_TIME, LC_MONETARY, LC_NAME, LC_ADDRESS,
LC_MEASUREMENT). I don't think it is a locale issue.
> - What happens if instead of Chrome you use Firefox or Konqueror or...?
It works, the problem only happens (for now...) if using Chrome. It
may be a subtle Chrome bug that only happens when using the clipboard
with Vim :?
> - What happens if instead of Console Vim you use gvim?
I don't have gvim on my system :(
Thanks, Tony :)
Bram Moolenaar
Raul wrote:
The text that xclip shows is only one of the possible contents. X11
uses atoms to select different types of text. Vim uses five different
ones, see src/ui.c, clip_x11_request_selection(). However, the cut
buffer only supports latin1. Perhaps Chrome puts multi-byte text in the
cut buffer?
--
hundred-and-one symptoms of being an internet addict:
136. You decide to stay in a low-paying job teaching just for the
free Internet access.
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
Raúl Núñez de Arenas Coronado
I'm not going to trim my original message so the thread is easier to
follow from this point on, specially if someone google for help.
Bram Moolenaar <B...@moolenaar.net> skribis:
I don't know. At first I thought that the problem may be related to the
atom used to request the contents, and I was even going to write a small
program to check this, but since any other application seems to work OK
(I still haven't been able to reproduce the problem with other
application except for console Vim), the procrastinator that lives in me
didn't write the program.
After seeing the code in src/ui.c, looks like the problem is that Vim
ends up using the cut_buffer0 to get the data. In that case, the problem
is different: Chrome is using cut buffers instead of selections. But cut
buffers are deprecated, so I don't know why the heck is Chrome using
them.
This looks wrong, since xclip says that the selections are being used,
so the content is there, so another option is that Chrome is using a
selection but the wrong atom to say what the selection contains, am I
right?
So, in any case, I should check where is putting Chrome the contents and
how: do you know of any X Window utility for doing this so I don't have
to write a program instead? My X Window knowledge is rusty, at best.
Since cut buffers are properties of the root window, should "xwininfo"
work here?
Thanks, Bram :)
Bram Moolenaar
Raulnac wrote:
Perhaps Chrome puts HTML in the selection?
--
hundred-and-one symptoms of being an internet addict:
154. You fondle your mouse.
Benjamin R. Haskell
>
> Raulnac wrote:
>
>> Saluton Bram :)
>>
>> I'm not going to trim my original message so the thread is easier to
>> follow from this point on, specially if someone google for help.
>>
>> Bram Moolenaar skribis:
[...]
> Perhaps Chrome puts HTML in the selection?
Running Google Chrome 6.0.437.1 (Official Build 49781)
VIM - Vi IMproved 7.2 (2008 Aug 9, compiled Aug 22 2010 15:00:27)
Included patches: 1-442
Chrome does put HTML in the selection. But, not in the one that's
broken.
I found this Chromium bug-report related to a clipboard problem:
http://code.google.com/p/chromium/issues/detail?id=34813
The actual problem doesn't look relevant, but there's a useful
clipboard/selection examining tool in one of the comments:
http://code.google.com/p/chromium/issues/detail?id=34813#c9
Downloaded: gtk_clipboard_dump.cc
Compiled: g++ $(pkg-config --cflags --libs gtk+-2.0) -o ~/bin/gtk_clipboard_dump ~/Download/gtk_clipboard_dump.cc
Copying the David Gómez sample text in Chrome, and running
gtk_clipboard_dump yields:
Desktop clipboard
9 available targets:
---------------
[format: TIMESTAMP / length: 8 / bits 32]: (time omitted)
[format: TARGETS / length: 72 / bits 32]: u_______q_______t_______w______________x_______G_______y_______z_______
[format: MULTIPLE]: NULL
[format: COMPOUND_TEXT / length: 12 / bits 8]: David Gómez
[format: STRING / length: 12 / bits 8]: David Gómez
[format: TEXT / length: 12 / bits 8]: David Gómez
[format: UTF8_STRING / length: 12 / bits 8]: David Gómez
[format: text/html / length: 785 / bits 8]: <meta http-equiv="content-type" content="text/html; charset=utf-8"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: 'Times New Roman'; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span class="Apple-style-span" style="border-collapse: collapse; color: rgb(80, 0, 80); font-family: arial, sans-serif; font-size: 13px; ">David Gómez</span></span>_
[format: text/plain / length: 12 / bits 8]: David Gómez
X clipboard
9 available targets:
---------------
[format: TIMESTAMP / length: 8 / bits 32]: (time omitted)
[format: TARGETS / length: 72 / bits 32]: u_______q_______t_______G_______w_______x______________|_______z_______
[format: MULTIPLE]: NULL
[format: UTF8_STRING / length: 12 / bits 8]: David Gómez
[format: COMPOUND_TEXT / length: 11 / bits 8]: David Gómez
[format: TEXT / length: 11 / bits 8]: David Gómez
[format: STRING / length: 11 / bits 8]: David Gómez
[format: text/plain;charset=utf-8 / length: 12 / bits 8]: David Gómez
[format: text/plain / length: 16 / bits 8]: David G\u00f3mez
--
Hope that's helpful,
Ben
Raúl Núñez de Arenas Coronado
First of all, sorry for the delay, but I've been busy as heck.
Second: Bram, looks like Chrome is putting HTML in the Desktop
clipboard, but not in the X clipboard, see the message below, Benjamin
has done an excellent research work.
Benjamin R. Haskell <v...@benizi.com> skribis:
>> Perhaps Chrome puts HTML in the selection?
>
> Running Google Chrome 6.0.437.1 (Official Build 49781) VIM - Vi
> IMproved 7.2 (2008 Aug 9, compiled Aug 22 2010 15:00:27) Included
> patches: 1-442
>
> Chrome does put HTML in the selection. But, not in the one that's
> broken.
>
> I found this Chromium bug-report related to a clipboard problem:
> http://code.google.com/p/chromium/issues/detail?id=34813
>
> The actual problem doesn't look relevant, but there's a useful
> clipboard/selection examining tool in one of the comments:
> http://code.google.com/p/chromium/issues/detail?id=34813#c9
> Downloaded: gtk_clipboard_dump.cc Compiled: g++ $(pkg-config --cflags
> --libs gtk+-2.0) -o ~/bin/gtk_clipboard_dump
> ~/Download/gtk_clipboard_dump.cc
>
> Copying the David Gómez sample text in Chrome, and running
> gtk_clipboard_dump yields:
Mmm, revealing... I'm going to do the same with another browser so we
can find what's the problem. Last resort will be gdbing Vim.
Thanks A LOT for your help, for posting the code for the test tool and
for all the information. Now I have a base to work.
> [format: COMPOUND_TEXT / length: 12 / bits 8]: David Gómez
> [format: STRING / length: 12 / bits 8]: David Gómez
> [format: TEXT / length: 12 / bits 8]: David Gómez
> [format: UTF8_STRING / length: 12 / bits 8]: David Gómez
All those "length: 12" make me think they're all encoded with UTF-8 and
not in latin1 (where length would be 11).
> [format: text/plain / length: 12 / bits 8]: David Gómez
Even this is encoded with UTF8 (I think...)
> X clipboard
[...]
> [format: COMPOUND_TEXT / length: 11 / bits 8]: David Gómez
> [format: TEXT / length: 11 / bits 8]: David Gómez
> [format: STRING / length: 11 / bits 8]: David Gómez
But these are encoded in latin1, and probably are the ones that Vim is
using. If so, the problem is in Chrome, not in Vim.
> Hope that's helpful,
A lot, Ben, at least to me. Let's see if Bram sees something here that
may be causing the problem. Otherwise I'll report the bug to the Chrome
people. I think that Chrome uses GTK, and if so, it should be using GTK
clipboard primitives. In that case, I'm afraid the problem may lie in
the GTK libraries, but that's weird since no other GTK program shows the
same behaviour :?
Raúl Núñez de Arenas Coronado
I've further investigate the issue, using the gtk_clipboard_dump
utility and Firefox to compare with Chrome.
I've included the output from the utility showing the clipboard
contents when copying exactly the same text from Chrome and Firefox.
Both browsers provide an UTF8_STRING entry in the desktop clipboard,
but Firefox doesn't provide X clipboard contents when Chrome does.
Attached files are encoded using utf8: Vim detects them as latin1
because they actually contain latin1 characters, so take that into
account.
Thanks for your help :)