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
