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
