can't copy from emacs and paste to os x

[dwalthour@…]

Starting in version 2.3.2.1, I can't copy from emacs and paste to os x

The inverse still works: copying from os x to emacs has no problem. Also, I can copy from other x11 apps like xterm and paste to os x without problem.

This appears to only be the case when I am running emacs 21.4.1 remotely and displaying back to my mac via ssh x11 forwarding. If I run an x11 version of emacs on my mac, copy and past works as expected.

Versions prior to 2.3.2.1 did not have this problem.

[arthurp@…]

I can confirm this on a MacBook Pro running 10.5.6. XQuartz 2.3.2 and 2.3.2.1 both exhibited this problem.

With more specificity:

• New, clean install of 10.5.6; installed Apple X11 then 2.3.2.1, then downgraded to 2.3.2
• Exhibits symptoms (fails to copy into clipboard) with emacs 21.4.1 on multiple hosts
• Symptoms persist across multiple local (MacOS) user profiles and remote usernames
• Emacs 22.2.1 and 22.3.1, even running on the same hosts, do not exhibit symptoms
• Only tested with ssh -Y (trusted X forwarding)

I was able to fix the problem by downgrading to 2.3.1 (deleting X11.app and ~/Library/Preferences/org.x.X11.plist, then running the package installer for 2.3.1) fixed all problems.

[jeremyhu@…]

Is emacs copying to CLIPBOARD or PRIMARY? Are you doing Edit->Copy in the X11.app menu bar to send the PRIMARY contents to NSPasteboard?

[arthurp@…]

How can I tell CLIPBOARD vs PRIMARY?

And yes (most often use Cmd+C which blinks the Edit menubar to indicate that's what's going on, but selecting Edit->Copy directly behaves identically).

[jeremyhu@…]

Are you able to paste that selection to other X11 windows (like xterm) with a middle click?

[arthurp@…]

Yes. I can select a string, paste to any other window within my X11 session with middle click, but only the previous contents of the MacOS clipboard will appear when I hit Command+V in a MacOS application.

(It does not matter when selecting the string whether I choose Edit -> Copy from the X11.app menu bar. If text was previously selected in another X11 application, eg xterm, then that is the text that will appear as "previous contents of the MacOS clipboard".)

[jeremyhu@…]

It sounds to me like emacs isn't claiming PRIMARY... since selecting Edit->Copy is actually copying the text that was selected in the other X11 application before you selected text in emacs. Further, newer versions of emacs reportedly work for you.

George, what are your thoughts?

[arthurp@…]

Yes, but when I carry out the below steps: a1) select text "aaaaa" in an xterm, then X11.app Edit->Copy a2) Edit->Paste into TextEdit yields "aaaaa" b1) select text "bbbbb" in TextEdit, Edit->Copy b2) Edit->Paste into TextEdit yields "bbbbb" c1) select text "ccccc" in Emacs 21.4.1, then X11.app Edit->Copy c2) Edit->Paste into TextEdit yields "bbbbb"

If I'm reading your interpretation above correctly, I would expect step c2) to yield "aaaaa".

Although 21.4.1 is a pretty old version of Emacs, it's the package available in CSAIL Debian 4.0 "etch" (the current stable Debian until...tomorrow, which means it'll still have wide distribution until all sites upgrade all machines to 5.0 "lenny").

[jeremyhu@…]

Yeah, based on your earlier report, I thought it would be "aaaaa" ... If you select text in xterm after c2 and do edit->copy, then paste it into TextEdit, will it paste the xterm's text?

[arthurp@…]

yes.

[jeremyhu@…]

Sounds like a bug in emacs that was fixed in the newer version...

[arthurp@…]

jeremyhu: probably so, yet Emacs 21.4.1 continues to write to the paste buffer in X-Win32, linux X servers, and XQuartz <= 2.3.1, and is relatively widely deployed. Is it not worth looking at what code changes in XQuartz might have caused this regression, and whether it's possible to correct that?

[jeremyhu@…]

I agree, and that's why I didn't close the bug ;)

The old emacs is probably doing something unconventional which other apps are handling. We just need to figure out how to handle it. Since it's fixed in newer versions of emacs, it's not too pressing, but I'd like to get it addressed in the 2.4.x timeframe.

[weasel@…]

this might be off-topic for the x server, but after installing the locales update (X11-Locales-2.3.3.2, and thanks for tthe update) i can get clipboard pasting w/ a little snippet like this:

(when (eq 0 (string-match "*-apple-darwin*" system-configuration))

(setq x-select-enable-clipboard t))

and setting the preferences to trigger back-forth on clipboard changes from either side (x or mac). the variable there 'forces' the CLIPBOARD updates when going through the kill ring.

[jeremyhu@…]

Closing as "duplicate", but it's just "duplicate" of the fact that CLIPBOARD is going to get majorly reworked and hopefully this will "just work" after that update. Since there isn't an easy test case to work with here, and the workaround is simple (update emacs), I'm not too concerned about this specific case... but if this problem persists after the clipboard update, please let me know.

[leho@…]

OS X 10.6.8, Xquartz 2.6.2

not entirely sure where to write this up (#320 is duplicate of this), but there's still some wonkyness left in pasteboard sync. after a reboot, i couldn't get an X11 app to copy data to OS X and it had been working fine before. ​this post on xquartz-dev gave a good tip about copying something from OS X side into X11 first. after doing this, pasteboard sync was also initialized, restored or whatnot in the other direction.

i can't seem to find the "open bug" that Jeremy in the post above refers to. is this it or...?