On 11 Apr 2002 at 15:27:27 +0900, "Stephen J. Turnbull" <stephen(a)xemacs.org&gt; wrote: You know, it seemed like a good idea last night when I was suffering from severe sleep deprivation. In the cold light of morning, I see several problems with it. When using own-clipboard and get-clipboard, the problem you mention can be solved by noting that, when no other application has changed the clipboard, the string returned by get-clipboard is EQ to the one last passed to own-clipboard. Also, I thought I needed to introduce a new variable to correctly handle the case where the same string is cut, copied, or killed multiple times. However, the patch I submitted has the property that last-interprogram-cut is always EQ to (car kill-ring), so we might as well use that and avoid a new variable. The killing blow is that this is entirely the wrong approach anyhow. The problem is really in own-clipboard/get-clipboard. Look at this excerpt from the docstring for interprogram-paste-function: Note that the function should return a string only if a program other than Emacs has provided a string for pasting; if Emacs provided the most recent string, the function should return nil. If it is difficult to tell whether Emacs or some other program provided the current string, it is probably good enough to return nil if the string is equal (according to `string=') to the last text Emacs provided. There's the problem; get-clipboard is returning a string when it should be returning nil. But now it gets weird. That function is defined in select.el. It doesn't really have access to anything that would tell if it XEmacs owns the selection or not, so it looks like we should peek into get-selection-internal, which is defined in select.c. It looks to me like that function ought to work something like this: If there is something in Vselection_alist that matches return nil Else return whatever the appropriate device wants to give us But look how hard that function works to find something on Vselection_alist to return! I don't want to suggest throwing all that code out without understanding why it is there. Can anybody shed some light on this? -- Jerry James james(a)xemacs.org