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:
>> 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.
>
> 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?
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 :)
--
Raúl "DervishD" Núñez de Arenas Coronado
Linux Registered User 88736 | http://www.dervishd.net
The revolution will not be televised
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
No comments:
Post a Comment