Bug in Patch 7.2.201: Can no longer cut&paste plain text from gvim to OpenOffice

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug in Patch 7.2.201: Can no longer cut&paste plain text from gvim to OpenOffice

lack-3
Ever since 7.2.201 it has become impossible to cut&paste from gvim
into OpenOffice.

I can paste from gvim to gvim, gvim to a terminal, gvim to almost
anywhere else, but not OpenOffice.

The cause?  When pasting into OpenOffice, we seem to be hitting the
escape hatch added in selection_get_cb() when clip_html = 0, info =
TARGET_HTML:

-----
    if (info != (guint)TARGET_STRING
#ifdef FEAT_MBYTE
            && (!clip_html || info != (guint)TARGET_HTML)
            && info != (guint)TARGET_UTF8_STRING
            && info != (guint)TARGET_VIMENC
#endif
            && info != (guint)TARGET_VIM
            && info != (guint)TARGET_COMPOUND_TEXT
            && info != (guint)TARGET_TEXT)
        return;
-----

So I'm trying to decipher the intent of the whole clip_html global
(which is of course set to true when clipboard=html)

The description in the help text says:
        html When the clipboard contains HTML, use this when
                        pasting.  When putting text on the clipboard, mark it
                        as HTML.  This works to copy rendered HTML from
                        Firefox, paste it as raw HTML in Vim, select the HTML
                        in Vim and paste it in a rich edit box in Firefox.
                        Only supported for GTK version 2 and later.
                        Only available with the |+multi_byte| feature.

What's not clear is what the behaviour should be if this option is not
on (and by default it is not)

When clip_html is on, it makes sense that we offer that applications
can receive 'text/html' data, and when they ask for it, they get it.
This works properly, great.

However, if clip_html is off, the current behaviour is that gvim still
offers that applications can receive text/html, but when they ask for
it, gvim returns nothing.  This seems a bit broken.

So the two possible fixes I can see:
 -> Continue to offer text/html in all cases, and fall back to
returning something else if clip_html is false?  If so, what should we
return?
 -> Only offer text/html as a possible selection target only if
clip_html is true (This I feel is more correct)

Furthermore, what is the intended behaviour if the contents of the
buffer in vim (ie, what we know according to 'ft') is *not* HTML, but
something else, like XML, C code, etc?  It seems a bit dangerous for
an app which is expecting actual text/html data to get something
completely different.  Should the text/html output perhaps encase
everything in a <pre> tag?

If I can get some feedback on what the behaviour should be, I will
gladly attempt writing this patch.

(Originated as a Gentoo bug report: http://bugs.gentoo.org/show_bug.cgi?id=308927)

--
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
Reply | Threaded
Open this post in threaded view
|

Re: Bug in Patch 7.2.201: Can no longer cut&paste plain text from gvim to OpenOffice

Tony Mechelynck
On 03/06/10 19:56, lack wrote:

> Ever since 7.2.201 it has become impossible to cut&paste from gvim
> into OpenOffice.
>
> I can paste from gvim to gvim, gvim to a terminal, gvim to almost
> anywhere else, but not OpenOffice.
>
> The cause?  When pasting into OpenOffice, we seem to be hitting the
> escape hatch added in selection_get_cb() when clip_html = 0, info =
> TARGET_HTML:
>
> -----
>      if (info != (guint)TARGET_STRING
> #ifdef FEAT_MBYTE
> &&  (!clip_html || info != (guint)TARGET_HTML)
> &&  info != (guint)TARGET_UTF8_STRING
> &&  info != (guint)TARGET_VIMENC
> #endif
> &&  info != (guint)TARGET_VIM
> &&  info != (guint)TARGET_COMPOUND_TEXT
> &&  info != (guint)TARGET_TEXT)
> return;
> -----
>
> So I'm trying to decipher the intent of the whole clip_html global
> (which is of course set to true when clipboard=html)
>
> The description in the help text says:
> html When the clipboard contains HTML, use this when
> pasting.  When putting text on the clipboard, mark it
> as HTML.  This works to copy rendered HTML from
> Firefox, paste it as raw HTML in Vim, select the HTML
> in Vim and paste it in a rich edit box in Firefox.
> Only supported for GTK version 2 and later.
> Only available with the |+multi_byte| feature.
>
> What's not clear is what the behaviour should be if this option is not
> on (and by default it is not)
>
> When clip_html is on, it makes sense that we offer that applications
> can receive 'text/html' data, and when they ask for it, they get it.
> This works properly, great.
>
> However, if clip_html is off, the current behaviour is that gvim still
> offers that applications can receive text/html, but when they ask for
> it, gvim returns nothing.  This seems a bit broken.
>
> So the two possible fixes I can see:
>   ->  Continue to offer text/html in all cases, and fall back to
> returning something else if clip_html is false?  If so, what should we
> return?
>   ->  Only offer text/html as a possible selection target only if
> clip_html is true (This I feel is more correct)
>
> Furthermore, what is the intended behaviour if the contents of the
> buffer in vim (ie, what we know according to 'ft') is *not* HTML, but
> something else, like XML, C code, etc?  It seems a bit dangerous for
> an app which is expecting actual text/html data to get something
> completely different.  Should the text/html output perhaps encase
> everything in a<pre>  tag?
>
> If I can get some feedback on what the behaviour should be, I will
> gladly attempt writing this patch.
>
> (Originated as a Gentoo bug report: http://bugs.gentoo.org/show_bug.cgi?id=308927)
>

IIUC, clipboard=html is meant to import raw HTML into Vim (with tags and
all), adit it, and send it back. (Again, IIUC) it's the user's
responsibility to check that whatever he "yanks" into "+ when
clipboard=html "makes sense" wherever it will be pasted next (and even
plain text can "make sense" as HTML, if you remember that any number of
consecutive whitespace characters will be interpreted as "either one
space, or, if necessary considering the width of the text container, one
linebreak"). (IIUC) one should leave 'clipboard' to not-HTML in most
cases, except temporarily when editing HTML source to be exchanged as
HTML with some other application. The "expected behaviour" when
(&clipboard !~ '\<html\>') would then (IIUC) be whatever Vim used to do
before that option value existed.

Note that ":set clipboard+=html" requires has('multi_byte').


Best regards,
Tony.
--
"The society which scorns excellence in plumbing as a humble activity
and tolerates shoddiness in philosophy because it is an exalted
activity will have neither good plumbing nor good philosophy ...
neither its pipes nor its theories will hold water."

--
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
Reply | Threaded
Open this post in threaded view
|

Re: Bug in Patch 7.2.201: Can no longer cut&paste plain text from gvim to OpenOffice

lack-3
On Jun 3, 9:15 pm, Tony Mechelynck <[hidden email]>
wrote:

> IIUC, clipboard=html is meant to import raw HTML into Vim (with tags and
> all), adit it, and send it back. (Again, IIUC) it's the user's
> responsibility to check that whatever he "yanks" into "+ when
> clipboard=html "makes sense" wherever it will be pasted next (and even
> plain text can "make sense" as HTML, if you remember that any number of
> consecutive whitespace characters will be interpreted as "either one
> space, or, if necessary considering the width of the text container, one
> linebreak"). (IIUC) one should leave 'clipboard' to not-HTML in most
> cases, except temporarily when editing HTML source to be exchanged as
> HTML with some other application. The "expected behaviour" when
> (&clipboard !~ '\<html\>') would then (IIUC) be whatever Vim used to do
> before that option value existed.

Thanks, Tony, I think that gives me the courage to attempt a proper
solution: Only present text/html as a DND or selection target when
clipboard contains 'html'.

The only thing I'm not sure about is how to get a callback all the way
down into gui_gtk_x11.c when someone does either
  :set clipboard+=html
or
  :set clipboard-=html

Since in both cases I think the proper action to take is to adjust the
GTK "section targets" and "dnd targets".

Anyone have any tips on the "right way" to do that?

--
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
Reply | Threaded
Open this post in threaded view
|

Re: Bug in Patch 7.2.201: Can no longer cut&paste plain text from gvim to OpenOffice

James Vega-3
On Fri, Jun 4, 2010 at 2:27 PM, lack <[hidden email]> wrote:

> The only thing I'm not sure about is how to get a callback all the way
> down into gui_gtk_x11.c when someone does either
>  :set clipboard+=html
> or
>  :set clipboard-=html
>
> Since in both cases I think the proper action to take is to adjust the
> GTK "section targets" and "dnd targets".
>
> Anyone have any tips on the "right way" to do that?
The attached patch seems to work for me.

--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <[hidden email]>

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

html_selection.diff (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bug in Patch 7.2.201: Can no longer cut&paste plain text from gvim to OpenOffice

Bram Moolenaar

James Vega wrote:

> On Fri, Jun 4, 2010 at 2:27 PM, lack <[hidden email]> wrote:
> > The only thing I'm not sure about is how to get a callback all the way
> > down into gui_gtk_x11.c when someone does either
> >  :set clipboard+=html
> > or
> >  :set clipboard-=html
> >
> > Since in both cases I think the proper action to take is to adjust the
> > GTK "section targets" and "dnd targets".
> >
> > Anyone have any tips on the "right way" to do that?
>
> The attached patch seems to work for me.

Thanks.  Looks good.  We could argue that OpenOffice is doing this
wrong, but since everybody has it we should add this workaround.

--
hundred-and-one symptoms of being an internet addict:
157. You fum through a magazine, you first check to see if it has a web
     address.

 /// Bram Moolenaar -- [hidden email] -- 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    ///

--
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
Reply | Threaded
Open this post in threaded view
|

Re: Bug in Patch 7.2.201: Can no longer cut&paste plain text from gvim to OpenOffice

Bram Moolenaar
In reply to this post by lack-3

Lack wrote:

Somehow I didn't get the original message in this thread.

> On Jun 3, 9:15 pm, Tony Mechelynck <[hidden email]>
> wrote:
> > IIUC, clipboard=html is meant to import raw HTML into Vim (with tags and
> > all), adit it, and send it back. (Again, IIUC) it's the user's
> > responsibility to check that whatever he "yanks" into "+ when
> > clipboard=html "makes sense" wherever it will be pasted next (and even
> > plain text can "make sense" as HTML, if you remember that any number of
> > consecutive whitespace characters will be interpreted as "either one
> > space, or, if necessary considering the width of the text container, one
> > linebreak"). (IIUC) one should leave 'clipboard' to not-HTML in most
> > cases, except temporarily when editing HTML source to be exchanged as
> > HTML with some other application. The "expected behaviour" when
> > (&clipboard !~ '\<html\>') would then (IIUC) be whatever Vim used to do
> > before that option value existed.
>
> Thanks, Tony, I think that gives me the courage to attempt a proper
> solution: Only present text/html as a DND or selection target when
> clipboard contains 'html'.
>
> The only thing I'm not sure about is how to get a callback all the way
> down into gui_gtk_x11.c when someone does either
>   :set clipboard+=html
> or
>   :set clipboard-=html
>
> Since in both cases I think the proper action to take is to adjust the
> GTK "section targets" and "dnd targets".
>
> Anyone have any tips on the "right way" to do that?

As far as I know this should not be needed.  An application lists the
targets it supports.  The client then tries these targets one by one
until there is one that works.

I can copy/paste between all my applications and Vim.  I suspect the
problem is on the other side.  But I'm not sure.  The GTK docs are
unclear about these things.

--
hundred-and-one symptoms of being an internet addict:
155. You forget to eat because you're too busy surfing the net.

 /// Bram Moolenaar -- [hidden email] -- 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    ///

--
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
Reply | Threaded
Open this post in threaded view
|

Re: Bug in Patch 7.2.201: Can no longer cut&paste plain text from gvim to OpenOffice

Peter Odding-3
In reply to this post by Bram Moolenaar
Bram Moolenaar wrote:
> James Vega wrote:
>> The attached patch seems to work for me.
>
> Thanks.  Looks good.  We could argue that OpenOffice is doing this
> wrong, but since everybody has it we should add this workaround.

Thanks everyone in this thread, patch 7.2.442 fixed the problem for me!
Now I can finally unlearn Ctrl-Shift-V + Enter when switching between
Vim and OpenOffice :-)

  - Peter Odding

--
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
Reply | Threaded
Open this post in threaded view
|

Re: Bug in Patch 7.2.201: Can no longer cut&paste plain text from gvim to OpenOffice

lack-3
Confirming: 7.2.442 looks like a perfect fix to me, thanks to everyone
involved!

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