Copy/cut/paste between unix vim under VNC and windows (again)

[w***@ichips.intel.com]

Bram (and anyone else interested),

This topic has been discussed a few times before, but I have, I think,
some new information.

First, the background:
I typically run vim in a linux x-windows session run by VNC
(vncserver). This has always presented a problem for the copy/paste
operations when enabling the mouse in vim due the fact the vim puts
selected text only in the PRIMARY selection, while VNC pulled from
CUT_BUFFER0 for pasting. This was typically worked around with
autocutsel, which copied the primary selection to the cut buffer.

I recently started using a new version of vnc from RealVNC
(www.realvnc.com), which works a little differently and does NOT work
with autocutsel. It has its own utility (vncconfig) that is supposed to
support copy/paste between the vnc session and the vnc viewer. This
isn't working properly.

I've indirectly reported these problems to the developers of RealVNC.
They are looking at a solution within vnc, but they had one comment
regarding vim that I'd like to pass along. I'm not communicating with
them directly, and there were several emails before this one, but I'm
wondering if this is a valid critique of the way vim is operating. Note
that I have the same problems copying from "gedit" to windows, so this
is not a vim only problem.

-----Original Message-----
From: Tristan Richardson
Sent: Friday, May 14, 2004 9:28 AM
Subject: RE: Cut/paste again
I've managed to compile vim version 6.2 with the GUI and reproduce the
problem.
I'm reasonably sure that it's a bug in vim.
When it acquires the PRIMARY selection it uses the special value
CurrentTime (0) as the timestamp. This is specifically disallowed by
the ICCCM (inter-client communications convention manual). The
timestamp on the selection must be a valid timestamp from an X event.
The VNC 4 code looks at the timestamps of the PRIMARY and CLIPBOARD
selections so that it transfers whichever is the most recent of them.
Because vim sets the timestamp to zero this doesn't work - though often
the first selection will get through, hence the behaviour you are
seeing.
I'll have a think about whether we can work round it somehow, but the
real solution is to fix the error at source :-)
Cheers
Tristan

Can vim use non-zero timestamps when it acquires the PRIMARY selection?

I've looked at what I think is the relevant code. In ui.c, it has:

int
clip_x11_own_selection(myShell, cbd)
Widget myShell;
VimClipboard *cbd;
{
if (XtOwnSelection(myShell, cbd->sel_atom, CurrentTime,
clip_x11_convert_selection_cb, clip_x11_lose_ownership_cb,
NULL) == False)
return FAIL;
return OK;
}


I don't have an ICCM, but the man page on XtOwnSelection says:

The XtOwnSelectionInrcremental procedure informs the
Intrinsics incremental selection mechanism that the speci-
fied widget wishes to own the selection. It returns True
if the specified widget successfully becomes the selection
owner or False otherwise. For more information about
selection, target, and time, see Section 2.6 of the Inter-
Client Communication Conventions Manual.


I've looked around the vim code and can't find ANYWHERE that CurrentTime
is declared. Ahhh - I search a little further and find it defined in
the X.h file as 0L.

I did a quick try at replacing the CurrentTime with time(NULL) in the
above code, but that doesn't work correctly. I also tried replacing
CurrentTime with XtLastTimestampProcessed(dpy), which also required
passing a pointer to the display in to the function. That didn't seem
to work either. Any other ideas from someone more familiar with this
code?

[Bram Moolenaar]

Post by w***@ichips.intel.com

-----Original Message-----
From: Tristan Richardson
Sent: Friday, May 14, 2004 9:28 AM
Subject: RE: Cut/paste again
I've managed to compile vim version 6.2 with the GUI and reproduce the
problem.
I'm reasonably sure that it's a bug in vim.
When it acquires the PRIMARY selection it uses the special value
CurrentTime (0) as the timestamp. This is specifically disallowed by
the ICCCM (inter-client communications convention manual). The
timestamp on the selection must be a valid timestamp from an X event.

[...]

My X manual indeed states that CurrentTime is not allowed here. It
mentions that the time of the event that ended the highlighting should
be used.

Post by w***@ichips.intel.com
I did a quick try at replacing the CurrentTime with time(NULL) in the
above code, but that doesn't work correctly. I also tried replacing
CurrentTime with XtLastTimestampProcessed(dpy), which also required
passing a pointer to the display in to the function. That didn't seem
to work either. Any other ideas from someone more familiar with this
code?

I don't know which function to use, but it must return a "Time" value.
Perhaps it can be found in a received event. Xlib.h has a Time field in
many event structs. But when we're in an xterm and using Visual mode
selection, we don't get events. Thus we must find another way to get
the current time in a Time type. Apparently it's an unsigned long and
has the time in milliseconds. But it doesn't say what zero means.
Perhaps the wall clock time, or the moment the X server was started?
--
BLACK KNIGHT: Come on you pansy!
[hah] [parry thrust]
[ARTHUR chops the BLACK KNIGHT's right arm off]
ARTHUR: Victory is mine! [kneeling]
We thank thee Lord, that in thy merc-
[Black Knight kicks Arthur in the head while he is praying]
The Quest for the Holy Grail (Monty Python)

/// Bram Moolenaar -- ***@Moolenaar.net -- http://www.Moolenaar.net \\\
/// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ Project leader for A-A-P -- http://www.A-A-P.org ///
\\\ Buy at Amazon and help AIDS victims -- http://ICCF.nl/click1.html ///

[w***@ichips.intel.com]

Date: Mon, 17 May 2004 22:08:15 +0200
Subject: Re: Copy/cut/paste between unix vim under VNC and windows (again)

Post by w***@ichips.intel.com

-----Original Message-----
From: Tristan Richardson
Sent: Friday, May 14, 2004 9:28 AM
Subject: RE: Cut/paste again
I've managed to compile vim version 6.2 with the GUI and reproduce the
problem.
I'm reasonably sure that it's a bug in vim.
When it acquires the PRIMARY selection it uses the special value
CurrentTime (0) as the timestamp. This is specifically disallowed by
the ICCCM (inter-client communications convention manual). The
timestamp on the selection must be a valid timestamp from an X event.

[...]

My X manual indeed states that CurrentTime is not allowed here. It
mentions that the time of the event that ended the highlighting should
be used.

Post by w***@ichips.intel.com
I did a quick try at replacing the CurrentTime with time(NULL) in the
above code, but that doesn't work correctly. I also tried replacing
CurrentTime with XtLastTimestampProcessed(dpy), which also required
passing a pointer to the display in to the function. That didn't seem
to work either. Any other ideas from someone more familiar with this
code?

I don't know which function to use, but it must return a "Time" value.
Perhaps it can be found in a received event. Xlib.h has a Time field in
many event structs. But when we're in an xterm and using Visual mode
selection, we don't get events. Thus we must find another way to get
the current time in a Time type. Apparently it's an unsigned long and
has the time in milliseconds. But it doesn't say what zero means.
Perhaps the wall clock time, or the moment the X server was started?

This gives a definition of the Time:

http://www.rahul.net/kenton/xglossary.html

"It is typically the time since the last server reset. Timestamp values
wrap around (after about 49.7 days)"

I've not found a way to get the current "Time".

I've done some hacking and have given feedback to the RealVNC people.
They _seem_ to be assuming that XtOwnSelection() will be called with an
updated timestamp every time the selection content changes. I _think_
maybe they are keying on the timestamp to determine if the selection has
been updated. That seems like a wrong thing to do - but I'm no X
windows programming expert.

[Bram Moolenaar]

Post by w***@ichips.intel.com

Post by Bram Moolenaar
My X manual indeed states that CurrentTime is not allowed here. It
mentions that the time of the event that ended the highlighting should
be used.

Post by w***@ichips.intel.com
I did a quick try at replacing the CurrentTime with time(NULL) in the
above code, but that doesn't work correctly. I also tried replacing
CurrentTime with XtLastTimestampProcessed(dpy), which also required
passing a pointer to the display in to the function. That didn't seem
to work either. Any other ideas from someone more familiar with this
code?

I don't know which function to use, but it must return a "Time" value.
Perhaps it can be found in a received event. Xlib.h has a Time field in
many event structs. But when we're in an xterm and using Visual mode
selection, we don't get events. Thus we must find another way to get
the current time in a Time type. Apparently it's an unsigned long and
has the time in milliseconds. But it doesn't say what zero means.
Perhaps the wall clock time, or the moment the X server was started?

http://www.rahul.net/kenton/xglossary.html
"It is typically the time since the last server reset. Timestamp values
wrap around (after about 49.7 days)"

Thus we can't use time() or something like that to get the value.
Good that get that cleared up.

Post by w***@ichips.intel.com
I've not found a way to get the current "Time".

The only thing I can think of is forcing the X server to send us an
event somehow. But it's quite complicated and involves a wait for the
server response, which would block Vim for a moment (esp. noticable on a
remote connection).

Post by w***@ichips.intel.com
I've done some hacking and have given feedback to the RealVNC people.
They _seem_ to be assuming that XtOwnSelection() will be called with an
updated timestamp every time the selection content changes. I _think_
maybe they are keying on the timestamp to determine if the selection has
been updated. That seems like a wrong thing to do - but I'm no X
windows programming expert.

It sounds like they program their server by the book, not by common
practice. Vim works fine on the X servers I used (and I've used quite a
few). Thus their strict implementation is causing trouble for us.