system() break clipboard text.

[Yukihiro Nakadaira]

Ubuntu-12.10
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

[Bram Moolenaar]

I can reproduce it. Strange.

--
A)bort, R)etry, P)lease don't bother me again

/// Bram Moolenaar -- Br...@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 ///

[John Little]

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

[Christian Brabandt]

Hi John!

On Do, 28 Feb 2013, John Little wrote:

> 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.

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
\uff41

This patch fixes it for me:
diff --git a/src/ui.c b/src/ui.c
--- 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);
+ else
+ status = XmbTextPropertyToTextList(X_DISPLAY, &text_prop,
&text_list, &n_text);
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.

regards,
Christian
--
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.

[Bram Moolenaar]

Thanks for the patch!

> 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.

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.

[Christian Brabandt]

Hi Bram!

On Fr, 01 M�r 2013, Bram Moolenaar wrote:

> > 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.
>
> If we can't do it right it's better to not set the clipboard.

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?

> 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.

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
Christian
--

[Bram Moolenaar]

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.

--
hundred-and-one symptoms of being an internet addict:

16. You step out of your room and realize that your parents have moved and
you don't have a clue when it happened.

[Bram Moolenaar]

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
characters.

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"

[Yukihiro Nakadaira]

On Fri, Mar 8, 2013 at 2:02 AM, Bram Moolenaar <Br...@moolenaar.net> wrote:

...

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.

I wrote patch for it.  Please check the attached patch.

I tested gtk2, athena and cui vim on ubuntu-12.10.

[Bram Moolenaar]

Yukihiro Nakadaira wrote:

> On Fri, Mar 8, 2013 at 2:02 AM, Bram Moolenaar <Br...@moolenaar.net> wrote:
>
> > ...
> > 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.
> >
>
> I wrote patch for it. Please check the attached patch.
> I tested gtk2, athena and cui vim on ubuntu-12.10.

Thanks, I'll try it out.

--
Everybody lies, but it doesn't matter since nobody listens.
-- Lieberman's Law