Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot copy text *into* Kate editor, copying text *from* Kate works fine. #15

Closed
mucki-at opened this issue Nov 13, 2020 · 158 comments
Closed
Assignees
Labels
bug Something isn't working clipboard-integration Windows clipboard integration

Comments

@mucki-at
Copy link

Environment

Windows build number: Microsoft Windows NT 10.0.21257.0
Your Distribution version: Ubuntu 20.04 LTS
Your WSLG version: 0.2.9.0

Steps to reproduce

  • Open kate
  • Open notepad (for verification)
  • Copy text in windows.
  • Paste in notepad (for verification)
  • try paste in kate -> no text pasted
  • copy text inside kate
  • Paste in notepad -> this direction works fine.

WSL logs:

  • Attach WSLg logs from /mnt/wslg

You can access the wslg logs using explorer at: \\wsl\<Distro-Name>\mnt\wslg (eg: \\wsl\Ubuntu-20.04\mnt\wslg)

  • puseaudio.log
  • weston.log
  • versions.txt

versions.txt is not copyable (missing permissions):
WSLG ( x86_64 ): 0.2.9+Branch.master.Sha.d49cb28cbf4be209347e3b48315081c1b38e4465
wayland: 8cd7c836eaceccc0e4ada7bdac43d86bfe3e0a0a
FreeRDP: 297cb96a30ed00e1d7cba1ae9035cfeff82dbfd6
weston: a17db71354ad1c453e10a15805d907c52425499c
pulseaudio: 2f0f0b8c3872780f15e275fc12899f4564f01bd5
sharedguestalloc: e2895c6a49105caaa651c05d4b96a46e5a621538

pulseaudio.log
weston.log

Expected behavior

copy/past of text works both directions

Actual behavior

can only copy text from linux to windows, but not other way round

@hideyukn88
Copy link
Member

hideyukn88 commented Nov 25, 2020

@mucki-at , I'm not able to repro this. Does this repro consistently for you or only sometime ? Copy/paste in both direction works fine for me.

@mucki-at
Copy link
Author

mucki-at commented Nov 25, 2020 via email

@hideyukn88
Copy link
Member

@mucki-at , I looked at attached weston.log from you, while I can't be 100% sure, but below can be clue, Below means when apps (notepad in your case) pasted text into Windows's clipboard, mstsc.exe informs Linux side about what formats (say text, html, bitmap...) in Windows' clipboard, so Linux side can pull those if supported, but below shows it has 0 formats in there, thus nothing can be copy from Windows side... I will see if I can have more extensive logging around this.

[12:26:14.475] Client: clipboard format list: numFormats:0
[12:26:14.475] RDP clipboard_client_format_list (0x7f2810003650)
[12:26:14.475] Client: clipboard format list: no formats are supported

@viniciusjarina viniciusjarina transferred this issue from another repository Apr 19, 2021
@spronovo
Copy link
Collaborator

I tried to reproduce this and couldn't either. We've done a lot of changes to the clipboard support and fixes many issues since that was originally open. Resolving for now, please let us know if you are still seeing issue on more recent build.

@devcircus
Copy link

Experiencing the same behavior as OP. It is random. Sometimes works, sometimes doesn't. Seems I can get it working if I copy and paste several times in other locations in windows before finally copying and pasting to the gui app I'm using.

@hideyukn88
Copy link
Member

@devcircus , would you please provide weston.log from \mnt\wslg ? it would be helpful if you can capture weston.log right after the issue occurs. thanks!

@IvanChepurnyi
Copy link

IvanChepurnyi commented Apr 28, 2021

I have the same issue as OP when try to work with my IDE in Linux, anything I copy from my windows does not get pasted into Linux GUI.
Here is a log, seems like it does not work with text/plain mime type with specified charset?

[19:49:54.271] xfixes selection notify event: owner 2097153
[19:49:54.271] our window, skipping
[19:49:55.018] selection request, CLIPBOARD, target TARGETS, property XAWT_SELECTION
[19:49:55.031] selection request, CLIPBOARD, target TARGETS, property XAWT_SELECTION
[19:49:55.039] selection request, CLIPBOARD, target UTF8_STRING, property XAWT_SELECTION
[19:49:55.040] RDP clipboard_data_source_send (0x7f9690000c90) fd:103, mime-type:"text/plain;charset=utf-8"
[19:49:55.040] RDP clipboard_data_source_send (0x7f9690000c90) specified format (text/plain;charset=utf-8.0.0) is not supported by client

Copying from terminal output works, but from browsers and other rich text sources - does not.

@hideyukn88
Copy link
Member

@IvanChepurnyi , yes, currently "text/plain;charset=utf-8.0.0" is not recognized. it has to be exactly "text/plain;charset=utf-8". would you please let me know what is your IDE software? and also it would be helpful if you can confirmed pasting from Windows works with other Linux app, such as Firefox and gedit? thanks!

@IvanChepurnyi
Copy link

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.

@chiqui3d
Copy link

chiqui3d commented May 4, 2021

I still have the same problem, from Windows to any WSL/Ubuntu software or Windows terminal(WSL, CMD and PowerShell) it works perfectly.

But if I copy it from any .log, .txt or software from WSL/Ubuntu it doesn't work in the following situations:

  1. Any Windows software: Works.
  2. Windows terminal:
    • WSL: does not work
    • CMD: does not work
    • PowerShell: doesn't work with right-click, but works with CTRL + V

@chiqui3d
Copy link

chiqui3d commented May 5, 2021

I also add that I have PHPStorm installed inside WSL and it does not work to paste from the Windows to any PHPStorm file.

Is there no solution for this?

@mmachatschek
Copy link

I also have this issue. Here is a dump of the logs produced while trying to do the following:

In Windows -> select text -> Ctrl + C -> in WSLg running app (PHPStorm) -> Ctrl + V
Result: Nothing happens

I also found that for Gitkraken it's not working too. Same problem as with PHPStorm.

In Gedit I can paste the content.

weston.log

[12:48:36.408] read 0 (available 65536, mask 0x4)
[12:48:36.408] non-incr transfer complete
[12:48:36.414] selection request, CLIPBOARD, target TARGETS, property XAWT_SELECTION
[12:48:36.545] selection request, CLIPBOARD, target TARGETS, property XAWT_SELECTION
[12:48:36.555] selection request, CLIPBOARD, target TARGETS, property XAWT_SELECTION
[12:48:36.562] selection request, CLIPBOARD, target UTF8_STRING, property XAWT_SELECTION
[12:48:36.563] RDP clipboard_data_source_send (0x7f26a8000b50) fd:81, mime-type:"text/plain;charset=utf-8"
[12:48:36.563] RDP clipboard_data_source_send (0x7f26a8000b50) specified format (text/plain;charset=utf-8.0.0) is not supported by client
[12:48:36.563] read 0 (available 65536, mask 0x4)
[12:48:36.563] non-incr transfer complete
[12:48:36.567] selection request, CLIPBOARD, target TARGETS, property XAWT_SELECTION
[12:48:36.699] selection request, CLIPBOARD, target TARGETS, property XAWT_SELECTION
[12:48:36.702] selection request, CLIPBOARD, target TARGETS, property XAWT_SELECTION
[12:48:36.704] selection request, CLIPBOARD, target UTF8_STRING, property XAWT_SELECTION
[12:48:36.705] RDP clipboard_data_source_send (0x7f26a8000b50) fd:81, mime-type:"text/plain;charset=utf-8"
[12:48:36.705] RDP clipboard_data_source_send (0x7f26a8000b50) specified format (text/plain;charset=utf-8.0.0) is not supported by client
[12:48:36.705] read 0 (available 65536, mask 0x4)
[12:48:36.705] non-incr transfer complete
[12:48:36.707] selection request, CLIPBOARD, target TARGETS, property XAWT_SELECTION

@spronovo spronovo reopened this May 6, 2021
@hideyukn88
Copy link
Member

@mmachatschek , thanks for reportng. I installed PhpStrom (2021.1.2) from JetBrains Toolbox and copied text from Windows notepad and pasted with "Ctrl+v" into PhpStrom, it seems working for me, see "copy test from Windows". Does this happen to you all the time? Also, if you haven't move up to the latest release of WSLg, version 1.0.19, please update and try again, thanks!

image

@chiqui3d
Copy link

chiqui3d commented May 6, 2021

@hideyukn88, Try copying several lines of text, for example the 3 lines you just typed, and see if it will paste into the editor.

@hideyukn88
Copy link
Member

@chiqui3d , thanks for tips, but I still can't repro. If we can see below error in your weston log. can you locate which has bold number with "not supported by client" error.

[19:49:55.040] RDP clipboard_data_source_send (0x7f9690000c90) specified format (text/plain;charset=utf-8.0.0) is not supported by client

And find matching number entry with "clipboard_client_format_list (0xXXXXXX) allocated", and just above lines shows the supported format. For example, in my case (below), which is working, I would like to see what you have from "clipboard_client_format_list". thanks!

[09:49:44.819] Client: clipboard_client_format_list clipboard format list: numFormats:4
[09:49:44.820] Client: clipboard_client_format_list clipboard formats[0]: formatId:13, formatName:CF_UNICODETEXT
[09:49:44.820] Client: clipboard_client_format_list clipboard formats[1]: formatId:16, formatName:CF_LOCALE
[09:49:44.820] Client: clipboard_client_format_list clipboard formats[2]: formatId:1, formatName:CF_TEXT
[09:49:44.820] Client: clipboard_client_format_list clipboard formats[3]: formatId:7, formatName:CF_OEMTEX
[09:49:44.820] Client: clipboard_client_format_list (0x7fffd80015b0) allocated
[09:49:44.820] Client: clipboard_client_format_list (0x7fffd80015b0) mine_type:"text/plain;charset=utf-8"
[09:49:44.820] RDP clipboard_data_source_publish (0x7fffd80015b0)
[09:49:44.820] RDP clipboard_data_source_send (0x7fffd80015b0) fd:79, mime-type:"text/plain;charset=utf-8"

@chiqui3d
Copy link

chiqui3d commented May 6, 2021

Ok, I just found weston log, and I got the same errors. But this can't be fixed? 90% of what I copy is in that format. With GWSL this didn't happen to me.

[23:03:04.717] RDP clipboard_data_source_publish (0x7fbdd8000c00)
[23:03:04.717] RDP clipboard_data_source_cancel (0x7fbdd8000f60)
[23:03:04.717] RDP clipboard_data_source_send (0x7fbdd8000c00) fd:80, mime-type:"text/html"
[23:03:04.717] RDP clipboard_data_source_send (0x7fbdd8000c00) request index:3 formatId:49381 Client side Registered Clipboard Format
[23:03:04.717] RDP clipboard_set_selection (base:0x7fbdd8000c00}
[23:03:04.717] RDP clipboard_data_source_unref (0x7fbdd8000f60): refcount:0
[23:03:04.761] Client: clipboard_client_format_data_response (0x7fbdd8000c00) flags:2, dataLen:0
[23:03:04.761] RDP clipboard_data_source_unref (0x7fbdd8000c00): refcount:1
[23:03:07.365] xfixes selection notify event: owner 2097153
[23:03:07.365] our window, skipping
[23:03:07.592] selection request, CLIPBOARD, target TARGETS, property XAWT_SELECTION
[23:03:07.643] selection request, CLIPBOARD, target TARGETS, property XAWT_SELECTION
[23:03:07.680] selection request, CLIPBOARD, target UTF8_STRING, property XAWT_SELECTION
[23:03:07.680] RDP clipboard_data_source_send (0x7fbdd8000c00) fd:80, mime-type:"text/plain;charset=utf-8"
[23:03:07.680] RDP clipboard_data_source_send (0x7fbdd8000c00) specified format (text/plain;charset=utf-8.0.0) is not supported by client
[23:03:07.680] read 0 (available 65536, mask 0x4)
[23:03:07.680] non-incr transfer complete
[23:03:07.685] selection request, CLIPBOARD, target TARGETS, property XAWT_SELECTION

@hideyukn88
Copy link
Member

@chiqui3d , thanks for checking, can you share entire weston.log ? or at least until where "clipboard_client_format_list" ?

@chiqui3d
Copy link

chiqui3d commented May 6, 2021

Ok, https://pastebin.com/bSzt80Y5

@hideyukn88
Copy link
Member

Thank you very much, below is what I need. What's happening here is, Windows side propagates both plain text and HTML format as available data format, and Linux side queried HTML format first, then plain text next against same data source, and this second query is failing. I will look into corresponding code path for this scenario, thanks!

[00:08:38.767] Client: clipboard_client_format_list clipboard format list: numFormats:5
[00:08:38.767] Client: clipboard_client_format_list clipboard formats[0]: formatId:49381, formatName:HTML Format
[00:08:38.767] Client: clipboard_client_format_list clipboard formats[1]: formatId:13, formatName:CF_UNICODETEXT
[00:08:38.767] Client: clipboard_client_format_list clipboard formats[2]: formatId:16, formatName:CF_LOCALE
[00:08:38.767] Client: clipboard_client_format_list clipboard formats[3]: formatId:1, formatName:CF_TEXT
[00:08:38.767] Client: clipboard_client_format_list clipboard formats[4]: formatId:7, formatName:CF_OEMTEX
[00:08:38.767] Client: clipboard_client_format_list (0x7fbdd8000bf0) allocated
[00:08:38.767] Client: clipboard_client_format_list (0x7fbdd8000bf0) mine_type:"text/html"
[00:08:38.767] Client: clipboard_client_format_list (0x7fbdd8000bf0) mine_type:"text/plain;charset=utf-8"
[00:08:38.767] RDP clipboard_data_source_publish (0x7fbdd8000bf0)
[00:08:38.767] RDP clipboard_data_source_cancel (0x7fbdd8000d50)
[00:08:38.767] RDP clipboard_data_source_send (0x7fbdd8000bf0) fd:80, mime-type:"text/html"
[00:08:38.767] RDP clipboard_data_source_send (0x7fbdd8000bf0) request index:3 formatId:49381 Client side Registered Clipboard Format
[00:08:38.767] RDP clipboard_set_selection (base:0x7fbdd8000bf0}
[00:08:38.767] RDP clipboard_data_source_unref (0x7fbdd8000d50): refcount:0
[00:08:38.796] Client: clipboard_client_format_data_response (0x7fbdd8000bf0) flags:2, dataLen:0
[00:08:38.796] RDP clipboard_data_source_unref (0x7fbdd8000bf0): refcount:1
[00:08:38.817] xfixes selection notify event: owner 2097153
[00:08:38.817] our window, skipping
[00:08:40.299] selection request, CLIPBOARD, target TARGETS, property XAWT_SELECTION
[00:08:40.348] selection request, CLIPBOARD, target TARGETS, property XAWT_SELECTION
[00:08:40.363] selection request, CLIPBOARD, target UTF8_STRING, property XAWT_SELECTION
[00:08:40.364] RDP clipboard_data_source_send (0x7fbdd8000bf0) fd:80, mime-type:"text/plain;charset=utf-8"
[00:08:40.364] RDP clipboard_data_source_send (0x7fbdd8000bf0) specified format (text/plain;charset=utf-8.0.0) is not supported by client

@NorseJedi
Copy link

I experience the same issue, both with PhpStorm and Google Chrome running in WSL.

I also experience issues with norwegian characters ("æ ø å Æ Ø Å") being pasted as "æ ø Ã¥ Æ Ø Ã…" into Windows. Let me know if you'd prefer I post a separate issue on that.

My weston.log is here: https://pastebin.com/VX7R2wtB

@hideyukn88
Copy link
Member

@ensnared , I think your case is tracked by #20.

@hideyukn88
Copy link
Member

@chiqui3d , would you please let me know what Windows application did you use to "copy" ?

In your case, actually the problem is, despite Windows side reports it supports both HTML and plain text, but when Linux side queried the HTML data, the response from Windows side is FAIL (= flags: 2 in below log message), thus following request of plain text is failed too (since we marked this data source invalid)

[00:08:38.796] Client: clipboard_client_format_data_response (0x7fbdd8000bf0) flags:2, dataLen:0

I tried same with Windows version of Firefox, copying simple text from web page, then it reports HTML and plain text as available formats and Linux quires HTML first, and succeeded, then query plain text, and it can successfully paste the text into PhpStrom, thus I would like to know what application did you use to copy at Windows side. Thanks!

[18:01:14.654] Client: clipboard_client_format_list clipboard format list: numFormats:9
[18:01:14.654] Client: clipboard_client_format_list clipboard formats[0]: formatId:49679, formatName:text/html
[18:01:14.654] Client: clipboard_client_format_list clipboard formats[1]: formatId:49453, formatName:HTML Format
[18:01:14.654] Client: clipboard_client_format_list clipboard formats[2]: formatId:49903, formatName:text/_moz_htmlco
[18:01:14.654] Client: clipboard_client_format_list clipboard formats[3]: formatId:50394, formatName:text/_moz_htmlin
[18:01:14.654] Client: clipboard_client_format_list clipboard formats[4]: formatId:13, formatName:CF_UNICODETEXT
[18:01:14.654] Client: clipboard_client_format_list clipboard formats[5]: formatId:1, formatName:CF_TEXT
[18:01:14.654] Client: clipboard_client_format_list clipboard formats[6]: formatId:50135, formatName:text/x-moz-url-p
[18:01:14.654] Client: clipboard_client_format_list clipboard formats[7]: formatId:16, formatName:CF_LOCALE
[18:01:14.654] Client: clipboard_client_format_list clipboard formats[8]: formatId:7, formatName:CF_OEMTEX
[18:01:14.654] Client: clipboard_client_format_list (0x7fffd8001f70) allocated
[18:01:14.654] Client: clipboard_client_format_list (0x7fffd8001f70) mine_type:"text/html" index:3 formatId:49453
[18:01:14.654] Client: clipboard_client_format_list (0x7fffd8001f70) mine_type:"text/plain;charset=utf-8" index:0 formatId:1
[18:01:14.654] RDP clipboard_data_source_publish (0x7fffd8001f70)
[18:01:14.655] RDP clipboard_data_source_cancel (0x7fffd8001d50)
[18:01:14.655] RDP clipboard_data_source_send (0x7fffd8001f70) fd:71, mime-type:"text/html"
[18:01:14.655] RDP clipboard_data_source_send (0x7fffd8001f70) request "text/html" index:3 formatId:49453 Client side Registered Clipboard Format
[18:01:14.655] RDP clipboard_set_selection (base:0x7fffd8001f70}
[18:01:14.655] RDP clipboard_data_source_unref (0x7fffd8001d50): refcount:0
[18:01:14.704] Client: clipboard_client_format_data_response (0x7fffd8001f70) flags:1, dataLen:1099
[18:01:14.705] RDP clipboard_data_source_write (0x7fffd8001f70) write completed (930 bytes)
[18:01:14.705] RDP clipboard_data_source_unref (0x7fffd8001f70): refcount:1
[18:01:19.472] RDP clipboard_data_source_send (0x7fffd8001f70) fd:71, mime-type:"text/plain;charset=utf-8"
[18:01:19.472] RDP clipboard_data_source_send (0x7fffd8001f70) request "text/plain;charset=utf-8" index:0 formatId:1 CF_TEXT
[18:01:19.489] Client: clipboard_client_format_data_response (0x7fffd8001f70) flags:1, dataLen:58
[18:01:19.489] RDP clipboard_data_source_write (0x7fffd8001f70) write completed (57 bytes)
[18:01:19.489] RDP clipboard_data_source_unref (0x7fffd8001f70): refcount:1

@chiqui3d
Copy link

chiqui3d commented May 7, 2021

Hello, I'm doing it with Chrome

@hideyukn88
Copy link
Member

@chiqui3d , thanks, I still can't reproduce the issue locally. On google chrome (Windows version), highlight the text (below), then Ctrl+c, now switch to PhpStrom, Ctrl+v, it's working fine for me.

image

@Hoffs
Copy link

Hoffs commented May 10, 2021

I'm experiencing this issue as well when yanking from Neovim and then trying to paste inside Alacritty terminal.

Same error as for others:

[18:17:06.871] RDP clipboard_data_source_send (0x7f0d6c000ae0) fd:89, mime-type:"text/plain;charset=utf-8"
[18:17:06.871] RDP clipboard_data_source_send (0x7f0d6c000ae0) specified format (text/plain;charset=utf-8.0.0) is not supported by client

Complete log from time of yank to paste:

[18:18:58.348] Client: clipboard_client_format_list clipboard format list: numFormats:4
[18:18:58.348] Client: clipboard_client_format_list clipboard formats[0]: formatId:13, formatName:CF_UNICODETEXT
[18:18:58.348] Client: clipboard_client_format_list clipboard formats[1]: formatId:16, formatName:CF_LOCALE
[18:18:58.348] Client: clipboard_client_format_list clipboard formats[2]: formatId:1, formatName:CF_TEXT
[18:18:58.348] Client: clipboard_client_format_list clipboard formats[3]: formatId:7, formatName:CF_OEMTEX
[18:18:58.348] Client: clipboard_client_format_list (0x7f0d6c000d00) allocated
[18:18:58.348] Client: clipboard_client_format_list (0x7f0d6c000d00) mine_type:"text/plain;charset=utf-8"
[18:18:58.348] RDP clipboard_data_source_publish (0x7f0d6c000d00)
[18:18:58.348] RDP clipboard_data_source_send (0x7f0d6c000d00) fd:90, mime-type:"text/plain;charset=utf-8"
[18:18:58.348] RDP clipboard_data_source_send (0x7f0d6c000d00) request index:0 formatId:1 CF_TEXT
[18:18:58.348] RDP clipboard_set_selection (base:0x7f0d6c000d00}
[18:18:58.349] Client: clipboard_client_format_data_response (0x7f0d6c000d00) flags:2, dataLen:0
[18:18:58.349] RDP clipboard_data_source_unref (0x7f0d6c000d00): refcount:1
[18:18:59.721] RDP clipboard_data_source_send (0x7f0d6c000d00) fd:89, mime-type:"text/plain;charset=utf-8"
[18:18:59.721] RDP clipboard_data_source_send (0x7f0d6c000d00) specified format (text/plain;charset=utf-8.0.0) is not supported by client

I can paste yanked text in Windows without issues, but not inside Alacritty (which is running using wslg). Also as others mentioned, sometimes it works right away, but it could be due to some other inputs.

I am using Neovim nightly with win32yank to directly integrate with windows clipboard: https://github.com/neovim/neovim/wiki/FAQ#how-to-use-the-windows-clipboard-from-wsl

I was able to reproduce it everytime by doing following:

  • Have Alacritty installed (installed using cargo in Debian) and Neovim with win32yank configured
  • start alacritty
  • echo "testdata" > test.txt
  • nvim -u NONE test.txt
  • :set clipboard=unnamedplus
  • vey (visual select, end of word, yank)
  • :q
  • CTRL+SHIFT+V (default Alacritty bind for paste)
  • tail -100 /mnt/wslg/weston.log
  • RDP clipboard_data_source_send (0x7f0d6c000ae0) specified format (text/plain;charset=utf-8.0.0) is not supported by client (I was able to paste yanked text inside Windows fine)

This was done inside Debian 10.9

WSLg ( x86_64 ): 1.0.17+3.Branch.master.Sha.a526dfd5ad03d126bb2d8c528f6c3563e86a40da
Mariner: VERSION="1.0.20210224"
FreeRDP: e4a2fc2053bd8c5f99455fcd08ffee7e5591567a
weston: fd961f5cd116c9358d82ce94d139c1578e21bd00
pulseaudio: 2f0f0b8c3872780f15e275fc12899f4564f01bd5

kernel: 5.10.16.3-microsoft-standard-WSL2

Also for comparison, executing same sequence of events (except Alacritty) purely inside Windows Terminal works perfectly fine.

@chiqui3d
Copy link

Sorry for the delay, it's true that sometimes it works, but other times it doesn't work for me, it does some strange things that I don't quite understand the behaviour, it would be ideal if it could support copy and paste in any format.

@eliezedeck
Copy link

I'm not too surprised to see Microsoft making a hype about something half-baked, as it has always done in the past. What's really disappointing is that they then leave you alone with a mediocre product that gets known bugs for years then they abandon it.

It's been months that I haven't been using WSL, I have chosen to just keep using my Mac (soon will get my M1 Max upgrade delivered), it's just a more serious environment for pro developers really. To me WSL is just a joke right now, yeah, I know there are a lot of developers on WSL, that's mainly I believe because they haven't seen what a Mac can do and they settle for less, not ever experiencing the difference.

I'm just subscribed to this just to see, just to see if they turn around. But yeah, like @edburns said, I hope some day this gets closed, and not just for the sake of closing a ticket, but really closed because the bug got fixed the right way, not dirty hacks all over the place. At most, I'd say bugs like these get fixed in 6 months, now it's almost 2 years or what, to me, it's just no longer a thing for Microsoft.

Well Microsoft, I hope you listen.

@jkbonfield
Copy link

For what it's worth, incase others come to this issue, I've been using WSL1 and VcXsrv as an X11 server instead. No need for wslg at all then and all the cut and paste problems vanish.

I've been using this for years and it's rock solid basically. I did try WSL2 (very complex install vs WSL1) and WSLg, but they just weren't an improvement for what I needed other than the slight speed gains in WSL2.

@cpbotha
Copy link

cpbotha commented Jun 12, 2022

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 #727 (comment) 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!

@whompyjaw
Copy link

For windows PGTK users:
Try this patch. You should be able to copy from PGTK emacs with it.

Thank you very much @masm11 !! I can confirm that with this patch copying from and to Emacs pgtk on Wayland in WSL both work without any work-arounds required.

It looks like your patch rejects any selection that's not of type CLIPBOARD, i.e. it ignores PRIMARY and SECONDARY. As @hideyukn88 has explained, indeed the WSL bridge only does selection of type CLIPBOARD and not PRIMARY.

This doesn't look like a change that could go into Emacs as is, as some users would probably expect primary and secondary to work on native (non-WSL) setups, or have I misunderstood?

Hi @cpbotha, I am in the same boat as you, running 29.0.50 emacs with pgtk and can't copy from Emacs to Windows. I have downloaded the patch but I am a little confused on how to add the hunks. When I try to in diff-mode I get "can't find the text to patch". The only + in the diff is

if(!EQ(selection, QCLIPBOARD))
  return Qnil;

But I assume I need to patch each line in each diff hunk? Sorry for noobness, I've never patched a diff before. So maybe I am missing something obvious. Maybe if @masm11 has time to comment.

To add, my line 347 of pgtkselect.c (of a newly cloned emacs) is GdkAtom conversion_fail_tag;... So I am not sure if the patching is suppose to remove it. I tried to move the file into ~/emacs/src/ but that didn't work either. I see that the diff is emacs/src/pgtkselect.c but shouldn't emacs have ~/ or something? EmacsWiki, manual, and internet doesn't seem to have much info for when diff-mode doesn't work. :/ Any insight would be helpful, thanks!

@cpbotha
Copy link

cpbotha commented Jul 5, 2022

@saltsucker You will need to use the patch command line tool to apply the patch. In your checked-out Emacs source top-level, try patch -p1 < win32.diff, and then configure and build emacs.

Are you able to build Emacs from source successfully?

@hideyukn88
Copy link
Member

@saltsucker, @cpbotha, please use #649 for the issue for primary selection with Wayland native Emacs. We are discussing weston upstream engineer to support this in our xwayland clipboard bridge, but not finalized yet.

And, to all participants on this issue, thank you very much for reporting the issue, trying out the fixes, and sharing your experience. At this point, the original issues with copy/paste between X11 applications and Windows, I believe, are addressed.

Please make sure to update WSL/WSLg from aka.ms/wslstorepage manually for moving up from WSLg 1.0.2x to 1.0.3x. (currently we are waiting a wsl.exe patch to distributed from Windows OS itself, then wsl --update will work for that update, but distribution delay is taking longer than we originally hoped).

Thus, I'm going to close this issue, and if there is any issue arise, please open as new issue with specific details, thank you!

@whompyjaw
Copy link

whompyjaw commented Jul 5, 2022

@saltsucker, @cpbotha, please use #649 for the issue for primary selection with Wayland native Emacs. We are discussing weston upstream engineer to support this in our xwayland clipboard bridge, but not finalized yet.

And, to all participants on this issue, thank you very much for reporting the issue, trying out the fixes, and sharing your experience. At this point, the original issues with copy/paste between X11 applications and Windows, I believe, are addressed.

Please make sure to update WSL/WSLg from aka.ms/wslstorepage manually for moving up from WSLg 1.0.2x to 1.0.3x. (currently we are waiting a wsl.exe patch to distributed from Windows OS itself, then wsl --update will work for that update, but distribution delay is taking longer than we originally hoped).

Thus, I'm going to close this issue, and if there is any issue arise, please open as new issue with specific details, thank you!

I am confused... I am on WSLg 1.0.39 and still have this issue?

WSL version: 0.61.4.0
Kernel version: 5.10.102.1
**WSLg version: 1.0.39**
MSRDC version: 1.2.3213
Direct3D version: 1.601.0
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22000.739

I downloaded the WSLg Preview from the Store. (Because I also needed to fix keys getting stuck and it was reported the Preview had the fix for this)
edit: @hideyukn88
edit2: Sorry, misread, we need at least 1.0.3x, but you are waiting for an update to Windows OS specifically, then I can run wsl --update and it will fix clipboard issue. Yes?

@hideyukn88
Copy link
Member

@saltsucker, no it does not fix the clipboard issue with Emacs with pgdk, it need the fix for #649. Thanks!

@whompyjaw
Copy link

patch -p1 < win32.diff

@cpbotha calling that command from ~/emacs fails.

user@host:~/emacs$ patch -p1 < win32.diff
patching file src/pgtkselect.c
Hunk #1 FAILED at 347.
Hunk #2 FAILED at 437.
Hunk #3 FAILED at 468.
Hunk #4 FAILED at 497.
Hunk #5 FAILED at 538.
5 out of 5 hunks FAILED -- saving rejects to file src/pgtkselect.c.rej

I tried it on a freshly cloned emacs as well. Yes I can build emacs from source successfully.

@whompyjaw
Copy link

@saltsucker, no it does not fix the clipboard issue with Emacs with pgdk, it need the fix for #649. Thanks!

Oh sorry, you're just saying for us to use that thread, heh... >.<

@RohanHart
Copy link

patch -p1 < win32.diff

@cpbotha calling that command from ~/emacs fails.

user@host:~/emacs$ patch -p1 < win32.diff
patching file src/pgtkselect.c
Hunk #1 FAILED at 347.
Hunk #2 FAILED at 437.
Hunk #3 FAILED at 468.
Hunk #4 FAILED at 497.
Hunk #5 FAILED at 538.
5 out of 5 hunks FAILED -- saving rejects to file src/pgtkselect.c.rej

I tried it on a freshly cloned emacs as well. Yes I can build emacs from source successfully.

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

@cpbotha
Copy link

cpbotha commented Jul 24, 2022

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.

@edburns
Copy link
Member

edburns commented Aug 1, 2022

Hello @hideyukn88 and @cpbotha I am glad to see this is closed. Please let me know if you want me to give this a test in my environment. I've been using the workaround (setq select-enable-clipboard nil) but perhaps this new fix you have is better?

@SamuelBanya
Copy link

SamuelBanya commented Feb 28, 2023

For windows PGTK users:

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

win32.diff.gz

@saltsucker You will need to use the patch command line tool to apply the patch. In your checked-out Emacs source top-level, try patch -p1 < win32.diff, and then configure and build emacs.

Are you able to build Emacs from source successfully?

This does NOT work on WSL2 using Ubuntu-22.04 on Windows 10 for compiling Emacs from source with your patch to supposedly fix the lack of the ability to copy and paste 'pgtk' apps.

Here are my steps (Though I do find it very annoying that no one included this because most people using WSL2 just want to try out Linux apps, and probably have no idea how to use default Linux tools by default... so you should have included every step in terms of how to actually use the patch you gave in the first place)

I used 'wget' to grab the file on Ubuntu 22.04 via WSL2:
wget https://github.com/microsoft/wslg/files/7964027/win32.diff.gz

I then unzipped the gunzip file '.gz' file you linked using the following command:
gzip -d win32.diff.gz

I then moved this patch file into the 'emacs' folder where I had git cloned the latest Git repo of Emacs:

mv win32.diff $HOME/Downloads/emacs

I then tried the following patch command with the following failure output:

sam@DESKTOP-N3NPDE2 ~/Downloads/emacs $ pwd
/home/sam/Downloads/emacs

sam@DESKTOP-N3NPDE2 ~/Downloads/emacs $ patch -p1 < win32.diff
patching file src/pgtkselect.c
Hunk #1 FAILED at 347.
Hunk #2 FAILED at 437.
Hunk #3 FAILED at 468.
Hunk #4 FAILED at 497.
Hunk #5 FAILED at 538.
5 out of 5 hunks FAILED -- saving rejects to file src/pgtkselect.c.rej

Hence, I am re-opening this issue as this is not resolved.

@SamuelBanya
Copy link

SamuelBanya commented Feb 28, 2023

UPDATE:
The above suggestion by @cpbotha to my Emacs config works to resolve the issue on WSL2 running Emacs (pgtk version) on Ubuntu-22.04 on Window 10, aka just add this to your Emacs config, and copy and paste clipboard FROM Emacs to Windows 10 works without an issue:

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.

@ferfebles
Copy link

My windows 11 laptop has become useless due to this bug.

I can't paste into Emacs from another application. It happened after the last windows 11 update.

Tried with (setq select-enable-clipboard nil) and using the wl-copy utility. It didn't work.

By now I'm resorting to writing content to a file with notepad, opening it in Emacs and then copying to the buffer that I need.

Any help?

@cpbotha
Copy link

cpbotha commented Mar 21, 2023

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.

@Safrone
Copy link

Safrone commented May 9, 2023

I had this issue pop up. It seemed to happen after I tried to copy and paste a large amount of data into a pycharm shell runnin g in wslg, afterwards I could copy and paste within pycharm but I couldn't copy from windows to wslg

@hideyukn88
Copy link
Member

@Safrone, would you please share your version info from wsl --version? thanks!

@Safrone
Copy link

Safrone commented May 10, 2023

@Safrone, would you please share your version info from wsl --version? thanks!

Sure:

Kernel version: 5.15.90.1
WSLg version: 1.0.51
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.19045.2728 

@hideyukn88
Copy link
Member

@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!

@gf9276
Copy link

gf9276 commented May 24, 2023

@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

@Raibows
Copy link

Raibows commented May 29, 2023

Having the same issue with #15 (comment)
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

@gf9276
Copy link

gf9276 commented May 29, 2023

Having the same issue with #15 (comment) 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

After so many years, this bug has not been fixed. Currently, wslg needs improvement.

@gf9276
Copy link

gf9276 commented Jun 17, 2023

@chiqui3d , thanks, I still can't reproduce the issue locally. On google chrome (Windows version), highlight the text (below), then Ctrl+c, now switch to PhpStrom, Ctrl+v, it's working fine for me.

image

Hello, why don't you try copying thousands of characters at once?

@hideyukn88
Copy link
Member

hideyukn88 commented Jun 19, 2023

@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 #743, thanks!

@przemo-hemmersbach
Copy link

Workaround that sometimes work:

Quickly doing Ctrl + V twice - it will paste a single clipboard item. Quick follow up Ctrl + Vs will start to duplicate inserted item as expected.

New notebook, so above maybe due to some accessibility feature I'm not aware off.

@rien333
Copy link

rien333 commented Nov 6, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working clipboard-integration Windows clipboard integration
Projects
None yet
Development

No branches or pull requests