Loading ...
Sorry, an error occurred while loading the content.

Re: system() break clipboard text.

Expand Messages
  • Christian Brabandt
    Hi Bram! ... 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
    Message 1 of 10 , Mar 1, 2013
    • 0 Attachment
      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
      --

      --
      --
      You received this message from the "vim_dev" 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

      ---
      You received this message because you are subscribed to the Google Groups "vim_dev" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
      For more options, visit https://groups.google.com/groups/opt_out.
    • 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
      Message 2 of 10 , Mar 2, 2013
      • 0 Attachment
        Christian Brabandt wrote:

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

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

        --
        --
        You received this message from the "vim_dev" 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

        ---
        You received this message because you are subscribed to the Google Groups "vim_dev" group.
        To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
        For more options, visit https://groups.google.com/groups/opt_out.
      • 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
        Message 3 of 10 , Mar 7, 2013
        • 0 Attachment
          Christian Brabandt wrote:

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

          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"

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

          --
          --
          You received this message from the "vim_dev" 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

          ---
          You received this message because you are subscribed to the Google Groups "vim_dev" group.
          To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
          For more options, visit https://groups.google.com/groups/opt_out.
        • Yukihiro Nakadaira
          ... I wrote patch for it. Please check the attached patch. I tested gtk2, athena and cui vim on ubuntu-12.10. -- Yukihiro Nakadaira -
          Message 4 of 10 , Mar 12, 2013
          • 0 Attachment
            On Fri, Mar 8, 2013 at 2:02 AM, Bram Moolenaar <Bram@...> 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.

            --
            Yukihiro Nakadaira - yukihiro.nakadaira@...

            --
            --
            You received this message from the "vim_dev" 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
             
            ---
            You received this message because you are subscribed to the Google Groups "vim_dev" group.
            To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
            For more options, visit https://groups.google.com/groups/opt_out.
             
             
          • Bram Moolenaar
            ... Thanks, I ll try it out. -- Everybody lies, but it doesn t matter since nobody listens. -- Lieberman s Law /// Bram Moolenaar -- Bram@Moolenaar.net --
            Message 5 of 10 , Mar 13, 2013
            • 0 Attachment
              Yukihiro Nakadaira wrote:

              > On Fri, Mar 8, 2013 at 2:02 AM, Bram Moolenaar <Bram@...> 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

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

              --
              --
              You received this message from the "vim_dev" 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

              ---
              You received this message because you are subscribed to the Google Groups "vim_dev" group.
              To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
              For more options, visit https://groups.google.com/groups/opt_out.
            Your message has been successfully submitted and would be delivered to recipients shortly.