|system() break clipboard text.||Yukihiro Nakadaira||2/28/13 12:21 AM|
Vim-7.3.843 gtk2 version
Steps to reproduce:
1. locale and &encoding is utf-8.
2. Insert non-latin1 text (for example U+FF41).
3. Yank the text to clipboard (v"+y).
4. Execute system command. :call system('ls') or :!ls
5. Put the text from clipboard ("+p).
Then, broken text is inserted.
This behavior seems introduced by 7.3.011 and 7.2.221.
7.3.011: X11 clipboard doesn't work in Athena/Motif GUI. First selection after a shell command doesn't work.
7.2.221: X cut_buffer0 text is used as-is, it may be in the wrong encoding.
Yukihiro Nakadaira - yukihiro...@gmail.com
|Re: system() break clipboard text.||Bram Moolenaar||2/28/13 7:35 AM|
I can reproduce it. Strange.
A)bort, R)etry, P)lease don't bother me again
/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
|Re: system() break clipboard text.||John Little||2/28/13 7:26 PM|
It happens for me (on Kubuntu 12.10, 7.3.843).
xclip -o reports
Error: target STRING not available
and other apps (I tried konsole, kate, firefox, LibreOffice) paste nothing.
Regards, John Little
|Re: system() break clipboard text.||Christian Brabandt||2/28/13 11:42 PM|
Interestingly, when using terminal vim, it returns some kind of utf
representation of the original buffer for the clipboard. E.g. I put
U+FF41 in the clipboard, call system('true') and :display + returns
This patch fixes it for me:
diff --git a/src/ui.c b/src/ui.c
@@ -2119,7 +2119,11 @@
text_prop.encoding = *type;
text_prop.format = *format;
text_prop.nitems = len;
- status = XmbTextPropertyToTextList(X_DISPLAY, &text_prop,
+ if (*type == utf8_atom)
+ status = Xutf8TextPropertyToTextList(X_DISPLAY, &text_prop,
+ &text_list, &n_text);
+ status = XmbTextPropertyToTextList(X_DISPLAY, &text_prop,
if (status != Success || n_text < 1)
In the gui, it seems, I get always garbage, since the for some reason I
think nothing is stored into the clipboard and therefore Vim tries to
restore the info from the CUT_BUFFER0, which can only hold latin1
encoded data and it breaks here. I tried uncommenting
clip_mch_lose_selection() in gui_gtk_x11.c and this seems to work, but I
am not really sure (could be, that this relies on some clipboard manager
to work) this is right.
20% aller Autounf�lle ging von alkoholisierten Autofahrern aus.
Das bedeutet: In 80% der Unf�lle war kein Alkohol im Spiele.
Was lehrt uns das: Alkoholisierte Autofahrer sind die besseren Fahrer.
|Re: system() break clipboard text.||Bram Moolenaar||3/1/13 5:32 AM|
Thanks for the patch!
If we can't do it right it's better to not set the clipboard.
We have to be careful not to own the selection when we are waiting for
an external command to finish, it would block the application that
requests the text.
hundred-and-one symptoms of being an internet addict:
8. You spend half of the plane trip with your laptop on your lap...and your
child in the overhead compartment.
|Re: system() break clipboard text.||Christian Brabandt||3/1/13 10:24 AM|
I would even say don't save the selection in the CUT_BUFFER0 at all or
only when the clipboard doesn't contain multibyte characters.
I am not sure, when the bug at clip_mch_lose_selection() occured, but I
think we could even enable it again. Nowadays a clipboard manager is
running often enough so that the data can then be stored in it and
correctly restored when querying the clipboard again.
Does the clipboard corruption actually also occur on Windows?
Yeah, but that seems not necessary for system() call, since that call
blocks vim anyway and the user doesn't see any feedback, while system()
is running. Nevertheless it is necessary for using :sh or :! commands.
Mit freundlichen Gr��en
|Re: system() break clipboard text.||Bram Moolenaar||3/2/13 4:34 AM|
When the command executed by system() obtains the current selection and
Vim owns it, you get a deadlock. I'm not sure if there is a timeout,
but I do remember that long ago it was possible to lockup completely.
16. You step out of your room and realize that your parents have moved and
you don't have a clue when it happened.
|Re: system() break clipboard text.||Bram Moolenaar||3/7/13 9:02 AM|
I included this patch, but it doesn't change anything for me.
After the system call the \uff41 character is always broken up in two
The problem is that x11_export_final_selection() only works for latin1.
Otherwise it just messes up the cut buffer.
We could avoid putting an invalid string in the cut buffer. Then when
there is a clipboard manager running it hopefully takes over the lost
selection text. I'll make a patch for this.
The only other solution I can think of is saving the owned selection and
restoring it after system() finishes. We would need to check that the
command executed by system() did not change the selection.
Time is an illusion. Lunchtime doubly so.
-- Ford Prefect, in Douglas Adams'
"The Hitchhiker's Guide to the Galaxy"
|Re: system() break clipboard text.||Yukihiro Nakadaira||3/12/13 7:56 AM|
On Fri, Mar 8, 2013 at 2:02 AM, Bram Moolenaar <Br...@moolenaar.net> wrote:
I wrote patch for it. Please check the attached patch.
I tested gtk2, athena and cui vim on ubuntu-12.10.
|Re: system() break clipboard text.||Bram Moolenaar||3/13/13 3:55 AM|
Thanks, I'll try it out.
Everybody lies, but it doesn't matter since nobody listens.
-- Lieberman's Law