Problem

(setq interprogram-cut-function
  (lambda (text)
  (start-process "wl-copy" nil "wl-copy" "--trim-newline" "--type" "text/plain;charset=utf-8" text))))

This workaround, gracefully provided by @cpbotha, works for the most part, but I discovered a bug. Specifically, with this in my init.el, emacs loses focuses whenever it is (1) fullscreen (run M-x toggle-frame-fullscreen), and (2) makes a call to wl-copy. This is extremely annoying.

One possible cause might be the following known “bug” of wl-copy (fromman wl-clipboard):

BUGS
       Unless the Wayland compositor implements the wlroots data-control protocol, wl-clipboard has to resort to  us‐
       ing  a hack to access the clipboard: it will briefly pop up a tiny transparent surface (window). On some desk‐
       top environments (in particular when using tiling window managers), this can cause visual issues such as brief
       flashing.

The question, then, is if the wlroots data-control protocol is properly implemented. If it isn’t, wl-copy might be spawning an invisible window, which would explain my focus-related problems.

Workaround

As a workaround for the previous workaround, I came up with the following. This solution uses the win32yank utility, a program which is written in rust, and is popular among those who use neovim on WSL. It handles unicode characters, a feature absent from the Windows-native clip.exe program, and it runs significantly faster than solutions centered on powershell.exe Set-Clipboard -Value <String>.

1. Install win32yank. The binary I downloaded from its Github Releases page was really slow on WSL for some reason, but the one I got through choco works pretty well:

choco install win32yank

1. Add the following to your init.el:

;; WSL clipboard fix
(setq interprogram-cut-function 
      (lambda (text)
        (with-temp-buffer
          (insert text)
          (call-process-region (point-min) (point-max) "win32yank.exe" nil 0 nil "-i" "--crlf"))))

Note that binaries installed through choco may not be in your PATH on WSL. On my end, anything installed through choco has always been available from WSL by default.

The patch needs to be redone as commit be35c92c90d455739a6ff9d4beefa2b35d044852 rewrote pgtkselect.c

I gave it a shot this weekend, but I was not able to port the !QCLIPBOARD rejection on the substantially modified pgtkselect.c.

In the meantime, I’m using this bit of code in my init to work around the issue:

(when (and (getenv "WAYLAND_DISPLAY") (not (equal (getenv "GDK_BACKEND") "x11")))
  (setq
   interprogram-cut-function
   (lambda (text)
     ;; strangest thing: gui-select-text leads to gui-set-selection 'CLIPBOARD
     ;; text -- if I eval that with some string, it mostly lands on the wayland
     ;; clipboard, but not when it's invoked from this context.
     ;; (gui-set-selection 'CLIPBOARD text)
     ;; without the charset=utf-8 in type, emacs / wl-copy will crash when you paste emojis into a windows app
     (start-process "wl-copy" nil "wl-copy" "--trim-newline" "--type" "text/plain;charset=utf-8"  text))))

It calls out to the wl-copy CLI utility, but it does work.

As someone who uses and develops on all three desktop platforms, I find the WSL2 implementation exceptionally useful.

WSLG has made and is still making enough progress so that my daily workflow, which involves a whole lot of Emacs pgtk running on WSL talking to the WSLG wayland compositor, is the smoothest it’s ever been.

Granted, I too am waiting for example for the window management to catch up (specifically Windows snapping for WSLG apps), but this requires changes to RDP which are being worked on as we speak, see https://github.com/microsoft/wslg/issues/727#issuecomment-1125569508 for in-progress screenshots. The performance and robustness of the WSLG connection justifies its use over my old X11 setups (I used to use X410, and sometimes also mobaXterm for this).

My clipboard issues have been fully resolved, thanks to @hideyukn88 (MS) working with @masm11 (an Emacs developer) to figure out and work around an unexpected inconsistency in clipboard handling between wayland, Emacs, and gtk (see #649).

To conclude: Thank you to everyone who has contributed to WSL and WSLG, your software adds value (and fun) to my workflow!

I use PHPStorm (IntelliJ IDEA variant) started from Linux and copy from various apps like Notepad, Notepad++, Edge, etc.

The only app from which copy-pasting works the Terminal app. Anything that resembles utf-8 contents seems not working.

I’ve also installed Firefox on Linux and tried to paste data from Windows, and all works flawlessly; only JetBrains IDE seems to fail.

I was surprised to learn some months back that Po Lu, who contributed massively to pgtk support in Emacs, recommends quite strongly against using it if you have the option of using plain old X. See this email (and its surrounding discussion) on the mailing list: https://lists.gnu.org/archive/html/emacs-devel/2022-04/msg01005.html

Mostly because of that, but also a little bit due to this bug and its work-around, I moved back to X11 Emacs on WSLg and have been enjoying a much smoother ride because of it.

also hitting this problem.

When copy from Chrome, to my editor on WSLg editor, it will paste correctly. However, once I copy-paste something at my editor, then copy some other content from Chrome to WSLg editor, it will still paste the previous content copied from my WSLg editor.

Started hitting this again. Re-enabled more verbose debugging to try to trap the case.

For windows PGTK users:

Try this patch. You should be able to copy from PGTK emacs with it.

win32.diff.gz

Ever since I started encountering this problem, I have made it a habit to tail -f weston.log in the hopes the problem would recur. Finally, it did. Here is the relevant output

[16:14:55.638] transfer complete
[16:14:55.756] wrote 120 (chunk size 120) of 120 bytes
[16:14:55.756] transfer complete
[16:14:59.523] xfixes selection notify event: owner 4194336
[16:14:59.671] wrote 69 (chunk size 69) of 69 bytes
[16:14:59.671] transfer complete
[16:14:59.673] write error to target fd: Bad file descriptor
[16:15:07.314] xfixes selection notify event: owner 4194336
[16:15:07.324] wrote 44 (chunk size 44) of 44 bytes
[16:15:07.324] transfer complete
[16:15:07.446] wrote 44 (chunk size 44) of 44 bytes
[16:15:07.446] transfer complete

This is the line that looks unique:

[16:14:59.673] write error to target fd: Bad file descriptor

This timestamp seems to coincide with the recurrence of the problem of losing the ability to paste into Emacs.

@eliezedeck and all others, thank you very much for trying out patiently. Currently, as we understand, this is caused by Windows is failing to respond with clipboard data after WSLg requested (even though there seems no fault at WSLg side), and we don’t know yet why Windows is failing, but one issues with WSLg is, once it entered failed state, it remains failed state forever. We are experimenting some re-try logic to request data again or reset, once this is confirmed it does help, we will update here, thanks for trying out WSLg and helping us!

I have just also tested this with a Wayland app that does NOT go through XWayland, e.g. gedit on Ubuntu 20.04. (I first tested with a build of the pgtk - nativecomp branch of Emacs in https://github.com/flatwhatson/emacs but rather chose gedit 3.36.2 as a more easily reproducible case)

I can copy text in gedit and paste in a Windows app. I can NOT copy in a Windows app and then paste into gedit (nothing gets pasted).

Perhaps more interestingly, even wl-paste -t text outputs nothing, so somehow the copy from the windows app (Edge in my case) is not correctly transferred to wayland. When I copy something from a Wayland app (gedit), wl-paste -t does output that exact copied text. @hideyukn88 Maybe this stripped-down wl-paste example can reproduce on your side?

This is the relevant error message in weston.log (both for gedit and wl-paste):

[11:11:45.971] Client: ClientGetAppidReq: WindowId:0x3e does not have appId, or not top level window.
[11:11:46.970] RDP clipboard_data_source_accept (base:0x7f5c64000b20) mime-type:"text/plain;charset=utf-8"
[11:11:46.970] RDP clipboard_data_source_send (0x7f5c64000b20) specified format "text/plain;charset=utf-8" index:0 formatId:0 is not supported by client

P.S. I just shutdown wsl and started over. I could paste successfully twice from Edge to gedit on wayland, and the third time stopped working.

Here is the log from just after startup:

[11:27:10.035] Client: LanguageImeInfo: ProfileType: 2 (TF_PROFILETYPE_KEYBOARDLAYOUT)
[11:27:10.035] Client: LanguageImeInfo: LanguageID: 0x409
[11:27:10.035] Client: LanguageImeInfo: LanguageProfileCLSID: GUID_NULL
[11:27:10.035] Client: LanguageImeInfo: ProfileGUID: GUID_NULL
[11:27:10.035] Client: LanguageImeInfo: KeyboardLayout: 0xa0010409
[11:27:19.395] RDP clipboard_data_source_accept (base:0x7fd814000cb0) mime-type:"text/plain;charset=utf-8"
[11:27:31.725] RDP clipboard_data_source_accept (base:0x7fd814000b60) mime-type:"text/plain;charset=utf-8"
[11:27:39.257] RDP clipboard_data_source_accept (base:0x7fd814000ec0) mime-type:"text/plain;charset=utf-8"
[11:27:39.257] RDP clipboard_data_source_send (0x7fd814000ec0) specified format "text/plain;charset=utf-8" index:0 formatId:0 is not supported by client
[11:27:43.508] RDP clipboard_data_source_accept (base:0x7fd814000ec0) mime-type:"text/plain;charset=utf-8"
[11:27:48.151] RDP clipboard_data_source_accept (base:0x7fd814000ab0) mime-type:"text/plain;charset=utf-8"
[11:27:48.151] RDP clipboard_data_source_send (0x7fd814000ab0) specified format "text/plain;charset=utf-8" index:0 formatId:0 is not supported by client

P.P.S. I repeated the experiment, copying from Edge and then running wl-paste -t text in Windows terminal. Works the first two times, and then stops working the third. I copied the first paragraph of this comment (try 1), then the third paragraph starting with “perhaps” (try 2), and then the paragraph starting with “P.S.” (try 3, did NOT work).

Log from just after startup:

[11:30:22.084] Audio sink thread: connection successful on socket (97).
[11:30:22.084] RDP Sink version (1 - 1)
[11:30:59.501] RDP clipboard_data_source_send (0x7f557c000d30) specified format "text/plain;charset=utf-8" index:0 formatId:0 is not supported by client

P.P.P.S. I continued with these experiments. When docker for desktop is running with its WSL2 backend, my copy paste breaks quite soon. Without docker for desktop, and hence no additional WSL2 instances but my main instance, copy paste continues working for many more tries.

Is it possible that the additional WSLg system distro instances that are started for each running WSL instance could be interfering with each other?

@gf9276, copy between Windows and Linux Wayland native application should work regardless of size, but there is issue from upstream branch which causes the problem between Wayland and X11 application, thus this impacts the copy between Windows and X11 since this goes through Windows to Wayland to X11, which is tracked by https://github.com/microsoft/wslg/issues/743, thanks!

Having the same issue with https://github.com/microsoft/wslg/issues/15#issuecomment-1560851310 like copying about 5k lines of codes will crash the copy/paste system of wslg It will not work anymore until a reboot…

Any help?

@hideyukn88

@Safrone, thanks for info, there is an issue filed with recent release, #1044, so I think there is possible regression, I will look into, thanks!

Hello, I have successfully reproduced this issue. When I copy a large amount of text from Windows 10 to Google Chrome in wslg, it triggers a copy failure and after that, I cannot copy anything from Windows 10 to wslg’s application (I have only tried Google Chrome and IDEA for now).

Kernel version: 5.15.90.1
WSLg version: 1.2.5.0
MSRDC version: 1.2.3770
Direct3D version: 1.608.2-61064218
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.19044.2965

I’ve switched to the MS Store version of WSL and it still doesn’t solve the problem for me. That’s what I got now:

WSL version: 0.51.2.0
Kernel version: 5.10.81.1
WSLg version: 1.0.30
Windows version: 10.0.22000.376

Funny enough, this update fixed another problem - now at least Emacs’s icon is properly displayed in the start menu and in the task bar. 😃

@sandric. please update WSL from Store app, https://www.microsoft.com/en-us/p/windows-subsystem-for-linux-preview/9p9tqf7mrm4r?activetab=pivot:overviewtab, thanks!

@edburns Hi, I just tested this setting and it seems to do nothing for my setup for some reason, the issue still occurs. I tried to check my wsl version, and somehow I don’t have version on mine, just status, which is strange since I’m on nightly windows 11 build and ran wsl --update just now, and I should have wslg because I have graphical emacs without any x server setup. Here’s the status output:

C:\WINDOWS\system32>wsl --status
Default Distribution: Ubuntu-20.04
Default Version: 2

Windows Subsystem for Linux was last updated on 22/01/2022
The Windows Subsystem for Linux kernel can be manually updated with 'wsl --update', but automatic updates cannot occur due to your system settings.
To receive automatic kernel updates, please enable the Windows Update setting: 'Receive updates for other Microsoft products when you update Windows'.
For more information please visit https://aka.ms/wsl2kernel.

Kernel version: 5.10.60.1

C:\WINDOWS\system32>

@bbatsov please also see my gist – it sets interprogram-cut-function to use wl-copy (but you could just as well do clip.exe) whenever you kill anything, as Emacs normally would do.

I’ve been using this workaround to get Emacs to copy stuff to Window’s clipboard:

(defun copy-selected-text (start end)
  (interactive "r")
    (if (use-region-p)
        (let ((text (buffer-substring-no-properties start end)))
            (shell-command (concat "echo '" text  "' | clip.exe")))))

Basically we just shell out to clip.exe on the WSL side, which works reliably, but we have to make sure we quote text properly. I’ve actually pasted this from Emacs using it. 😄

I would be very interested in getting access to that pre-release build @edburns and @hideyukn88 😃

I can’t run the store-version of wsl, because of issues with Windows interop breaking ( https://github.com/microsoft/WSL/issues/7754 ) and not being able to SSH into store-version of WSL ( https://github.com/PowerShell/Win32-OpenSSH/issues/1632 ), so this means I’m dependent on the “system” versions that get published here on the github, unless someone knows of a better solution.

In short: I woud be grateful for updated WSL packages that can be downloaded from here (or elsewhere), and not from the MS store.

People might also be interested in my Emacs work-around for the current clipboard issues, it uses wl-copy and gets copy-pasting mostly working in and out of latest master pgtk Emacs on WSL Wayland: https://gist.github.com/cpbotha/fdd2c5ab3d22a33679c546323ea3bc0b

@hideyukn88 after a few tests, here is the relevant log:

Step 1

[10:54:48.586] xfixes selection notify event: owner 4194335
[10:54:48.588] RDP clipboard_data_source_cancel (0x7f83e4000b20:transferred)
[10:54:48.588] RDP clipboard_data_source_cancel (0x7f83e4000b20:cenceled)
[10:54:48.588] RDP clipboard_set_selection (base:0x5602e255e030)
[10:54:48.588] RDP clipboard_data_source_unref (0x7f83e4000b20:cenceled): refcount:0
[10:54:48.588] RDP clipboard_set_selection (base:0x5602e255e030) available formats[0]: text/plain;charset=utf-8
[10:54:48.588] RDP clipboard_set_selection (base:0x5602e255e030) supported formats[0]: 13: CF_UNICODETEXT
[10:54:48.589] Client: clipboard_client_format_list_response msgFlags:0x1
[10:54:48.595] wrote 313 (chunk size 313) of 313 bytes
[10:54:48.595] transfer complete

Here, I’m in Emacs (WSLg) and copy a text selection from the buffer.

Step 2

[10:55:03.227] Client: clipboard_client_format_list clipboard format list: numFormats:9
[10:55:03.227] Client: clipboard_client_format_list clipboard formats[0]: formatId:49551, formatName:text/html
[10:55:03.227] Client: clipboard_client_format_list clipboard formats[1]: formatId:49375, formatName:HTML Format
[10:55:03.227] Client: clipboard_client_format_list clipboard formats[2]: formatId:49781, formatName:text/_moz_htmlco
[10:55:03.227] Client: clipboard_client_format_list clipboard formats[3]: formatId:49785, formatName:text/_moz_htmlin
[10:55:03.227] Client: clipboard_client_format_list clipboard formats[4]: formatId:13, formatName:CF_UNICODETEXT
[10:55:03.227] Client: clipboard_client_format_list clipboard formats[5]: formatId:1, formatName:CF_TEXT
[10:55:03.227] Client: clipboard_client_format_list clipboard formats[6]: formatId:49786, formatName:text/x-moz-url-p
[10:55:03.227] Client: clipboard_client_format_list clipboard formats[7]: formatId:16, formatName:CF_LOCALE
[10:55:03.227] Client: clipboard_client_format_list clipboard formats[8]: formatId:7, formatName:CF_OEMTEX
[10:55:03.227] Client: clipboard_client_format_list (0x7f83e4000f30:allocated) allocated
[10:55:03.227] Client: clipboard_client_format_list (0x7f83e4000f30:allocated) mine_type:"text/html" index:4 formatId:49375
[10:55:03.227] Client: clipboard_client_format_list (0x7f83e4000f30:allocated) mine_type:"text/plain;charset=utf-8" index:0 formatId:13
[10:55:03.227] Client: clipboard_client_format_list (0x7f83e4000f30:allocated) mine_type:"STRING" index:1 formatId:1
[10:55:03.227] RDP clipboard_data_source_publish (0x7f83e4000f30:format list ready)
[10:55:03.227] RDP clipboard_data_source_send (0x7f83e4000f30:published) fd:77, mime-type:"text/html"
[10:55:03.227] RDP clipboard_data_source_send (0x7f83e4000f30:request data) request "text/html" index:4 formatId:49375 Client side Registered Clipboard Format
[10:55:03.227] RDP clipboard_set_selection (base:0x7f83e4000f30)
[10:55:03.228] Client: clipboard_client_format_data_response (0x7f83e4000f30:request data) flags:1 dataLen:263
[10:55:03.228] Client: clipboard_client_format_data_response (0x7f83e4000f30:received data:0)
[10:55:03.228] RDP clipboard_data_source_write (0x7f83e4000f30:received data) fd:77
[10:55:03.228] RDP clipboard_process_html (0x7f83e4000f30:received data): receive (110 bytes)
[10:55:03.228] RDP clipboard_data_source_write (0x7f83e4000f30:transferring) wrote 110 bytes, remaining 0 bytes
[10:55:03.228] RDP clipboard_data_source_write (0x7f83e4000f30:transferred) write completed (110 bytes)
[10:55:03.228] RDP clipboard_data_source_unref (0x7f83e4000f30:transferred): refcount:1

Here, I switched back to Firefox (Windows) and copy some text from a webpage.

Step 3

After this, I switch back to Emacs (WSLg) and use its “yank” command (pasting). This doesn’t produce any log in the weston.log and it is pasting the text I copied from Emacs at step 1 and not the one from Firefox.

Step 4

[10:55:38.612] Client: ClientSyscommand: WindowId:0x4, surface:0x0x5602e25ce020, command:SC_MINIMIZE (0xf020)
[10:55:38.619] xfixes selection notify event: owner 2097153
[10:55:38.619] our window, skipping
[10:55:38.936] Client: ClientSyscommand: WindowId:0x4, surface:0x0x5602e25ce020, command:SC_RESTORE (0xf120)

Here I use the keyboard shortcut associated to the taskbar entry (Emacs is in second position so Win+2) to send the window to the backend and then to the foreground again.

Step 5

[10:55:52.580] selection request, CLIPBOARD, target UTF8_STRING, property _EMACS_TMP_
[10:55:52.581] RDP clipboard_data_source_send (0x7f83e4000f30:transferred) fd:77, mime-type:"text/plain;charset=utf-8"
[10:55:52.581] RDP clipboard_data_source_send (0x7f83e4000f30:request data) request "text/plain;charset=utf-8" index:0 formatId:13 CF_UNICODETEXT
[10:55:52.582] Client: clipboard_client_format_data_response (0x7f83e4000f30:request data) flags:1 dataLen:82
[10:55:52.582] Client: clipboard_client_format_data_response (0x7f83e4000f30:received data:0)
[10:55:52.583] RDP clipboard_data_source_write (0x7f83e4000f30:received data) fd:77
[10:55:52.583] RDP clipboard_process_text_utf8 (0x7f83e4000f30:received data): receive (40 bytes)
[10:55:52.583] RDP clipboard_data_source_write (0x7f83e4000f30:transferring) wrote 40 bytes, remaining 0 bytes
[10:55:52.583] RDP clipboard_data_source_write (0x7f83e4000f30:transferred) write completed (40 bytes)
[10:55:52.583] RDP clipboard_data_source_unref (0x7f83e4000f30:transferred): refcount:1
[10:55:52.583] read 40 (available 65536, mask 0x5)
[10:55:52.583] nothing happened, buffered the bytes
[10:55:52.583] read 0 (available 131032, mask 0x4)
[10:55:52.583] non-incr transfer complete
[10:55:52.583] selection request, CLIPBOARD, target UTF8_STRING, property _EMACS_TMP_
[10:55:52.583] RDP clipboard_data_source_send (0x7f83e4000f30:transferred) fd:77, mime-type:"text/plain;charset=utf-8"
[10:55:52.583] RDP clipboard_data_source_write (0x7f83e4000f30:received data) fd:77
[10:55:52.583] RDP clipboard_process_text_utf8 (0x7f83e4000f30:received data): receive (40 bytes)
[10:55:52.583] RDP clipboard_data_source_write (0x7f83e4000f30:transferring) wrote 40 bytes, remaining 0 bytes
[10:55:52.583] RDP clipboard_data_source_write (0x7f83e4000f30:transferred) write completed (40 bytes)
[10:55:52.583] RDP clipboard_data_source_unref (0x7f83e4000f30:transferred): refcount:1
[10:55:52.583] read 40 (available 65536, mask 0x5)
[10:55:52.583] nothing happened, buffered the bytes
[10:55:52.583] read 0 (available 131032, mask 0x4)
[10:55:52.583] non-incr transfer complete

Here I use the yank (paste) command again and it copies the text from Firefox as expected.

Hope this helps.

I’m having a similar issue - in weston.log I see the following message:

[22:26:30.579] selection request, CLIPBOARD, target TARGETS, property _WL_SELECTION
[22:26:30.580] selection request, CLIPBOARD, target UTF8_STRING, property _WL_SELECTION
[22:26:30.580] selection request, CLIPBOARD, target UTF8_STRING, property _WL_SELECTION
[22:26:30.580] outstanding selection exist 

Then trying to paste:

[22:26:53.520] selection request, CLIPBOARD, target UTF8_STRING, property XCLIP_OUT
[22:26:53.520] outstanding selection exist
[22:27:11.694] selection request, CLIPBOARD, target UTF8_STRING, property XCLIP_OUT
[22:27:11.694] outstanding selection exist

And I found a way to repro:

• Double-click to select some text in WSLg (I’m using Tilix, but also happened with kitty)
• Open something that has clipboard access (i.e. vim)
• Yank a line (yy)
• “outstanding selection exist” show up; pasting causes errors in both Windows and WSL (in Windows it crashes)

@Hoffs, thanks, yes, we addressed that particular issue in WSLg 1.0.23, thanks!

It works for me initially (freshly started) or after reboot, then after a while (multiple computer Sleep, various apps used in the mean-time and one wsl --shutdown to save memory) it stopped working.

UPDATE

• It works again after singing-out of my account and logging-back in
• This applies to all apps, not just IDE-specific
• Once it stops working, I have no workaround to make it work again

As a work-around until a fix, may be a way to restart some service / process or anything in WSL to reset the clipboard feature.