On Wed, 18 Jan 2006, Stahlman Brett wrote: > > > Recently, I built a Cygwin X-enabled Vim from the Unix sources on my > > > Windows machine. Everything seemed to work well until I attempted to > > > use the clipboard. The first attempt worked, but subsequent attempts to > > > copy text in Vim and paste to a native Windows application failed. (The > > > original text was pasted each time.) > > > > > > I looked into the issue, and actually wrote a patch for Unix Vim that > > > allows me to use the clipboard normally for pasting to native Win > > > applications. However, Bram Moolenaar of Vim insists (and I have come to > > > agree) that the problem is not with Vim but with the Cygwin X > > > implementation. Here's the problem as I understand it... > > > > > > When an X app such as Vim wants to obtain selection ownership, it calls > > > a function such as XtOwnSelection (or the analogous toolkit-specific > > > wrapper). Cygwin X processes this request by opening the Windows > > > clipboard and calling SetClipboardData with a NULL data pointer, > > > signifying that Windows should send a WM_RENDERFORMAT message when > > > selection data is required for pasting into a native Windows > > > application. This works fine for the first selection. The problem occurs > > > when the user of the X app returns to the X app and changes the > > > selection. In general, the X app will not make another call to > > > XtOwnSelection (or the analogous function) because it already owns the > > > selection and assumes it will communicate the changed data to X only > > > when its callback function is called; i.e., when the selection is > > > requested by another app. Unfortunately, the callback will not be called > > > upon subsequent paste attempts for the following reason: Windows sends > > > the WM_RENDERFORMAT message to Cygwin X's xwinclip window if and only if > > > it believes the data it received in response to the last WM_RENDERFORMAT > > > message is no longer valid. From Windows' standpoint, if there have been > > > no intervening calls to OpenClipboard / SetClipboardData, the clipboard > > > is unchanged, and there's no reason to send another WM_RENDERFORMAT > > > message to the clipboard owner (xwinclip)! Thus, once a given X app owns > > > the selection, subsequent paste operations into a native Windows > > > application will always result in a paste of the initial selection made > > > in the X app! The data pasted into Windows apps will not change until > > > the selection owner changes. > > > > > > The patch I implemented for Vim worked by forcing a change of selection > > > owner every time the selection within Vim changed. The solution was a > > > bit messy, as it required ignoring the "lose selection" callback, and in > > > the case of GTK, required processing X events between the call to > > > "disown" and "own" selection. Also, this solution is inefficient, as > > > multiple messages (e.g., WM_DESTROYCLIPBOARD, WM_DRAWCLIPBOARD) result > > > from every change of selection, and the selection may change rapidly > > > when, for example, you're selecting text with the mouse. Bram's other > > > argument against expecting X applications to implement workarounds such > > > as this is that it's not supposed to be necessary. There is no > > > requirement that an X app make a call into X every time the selection > > > changes. His suggestion (if I understood it correctly), which I believe > > > is very feasible, is to have XWin re-call SetClipboardData with a NULL > > > data pointer after processing each and every WM_RENDERFORMAT message. > > > This would effectively invalidate the data in the clipboard after each > > > time it was requested, forcing Windows to request it from xwinclip every > > > time the user of a Windows app performs a paste. Is there any reason why > > > this solution is not feasible? Have I misunderstood something about the > > > nature of the problem? > > > > I'm not very familiar with the details of how the clipboard handling is > > implemented in Cygwin/X (though I do know that there is a choice of the > > external xwinclip application and the internal -clipboard handling). The > > way applications like Exceed seem to do it is by relinquishing clipboard > > ownership on losing focus, and reacquiring the clipboard on getting the > > focus. Perhaps this approach will also work for Cygwin/X? > > Igor > > It might work, but that would require all X applications to implement a > workaround for what appears to be a Cygwin X bug.
I think you misunderstood my point. What I was saying was that the X server relinquishes the clipboard upon *any* of the X applications on that server losing focus to a Windows application, and then reacquires it whenever the focus comes back to any X application on that display. > This is the main reason the Vim owner wouldn't include my patch, even > though it fixes the clipboard problem. I believe his reasoning is, "if > the fault is Cygwin X's, then so should be the remedy". While I agree in > principle, I will, of course, continue to use the patch until it's fixed > in Cygwin. I agree with his reasoning. This is a bug in Cygwin/X, and your analysis may be helpful to the developers. But what would be even more helpful is a patch. Would you be willing to build the XWin server and try out the proposed fix at the server level? > Incidentally, you mentioned Exceed having had to come up with a > workaround as well. Is this problem known to the XWin developers? I > didn't see anything in the TODO, but I can't imagine that something like > this hasn't been reported by now. I'm just observing this from the way Exceed works (messages, etc). I haven't seen Exceed source code, so this is conjecture at best. But there should be no reason it wouldn't work for Cygwin/X... BTW, a workaround at the Exceed level would be equivalent to changing XWin.exe appropriately, not the applications. > Incidentally, the external xwinclip application is supposed to be > obsolete now, I think. I believe new development may be taking place > only on the integrated version, but I could be wrong. There were reports of problems with the integrated version that were absent in xwinclip -- I'd guess both would be used for some time yet. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_ [EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`' -. ;-;;,_ Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! "Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte." "But no -- you are no fool; you call yourself a fool, there's proof enough in that!" -- Rostand, "Cyrano de Bergerac" -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/