Paste from clipboard doesn&#39;t always work #18807

@zadjii-msft commented on GitHub (Nov 2, 2022):

What application is running in the Terminal that you're pasting into? How are you pasting (ctrl+shift+v, right mouse button, from the command palette...)/?

Without knowing more about the application in question, I'm not sure how we'd be able to figure out what "older clipboard methodology" they're using which we're apparently not supporting. Maybe they're setting a specific type of clipboard format (RTF? HTML?) that we're not looking for, but notepad++ can?

@zadjii-msft commented on GitHub (Nov 2, 2022): What application is running in the Terminal that you're pasting into? How are you pasting (<kbd>ctrl+shift+v</kbd>, right mouse button, from the command palette...)/? Without knowing more about the application in question, I'm not sure how we'd be able to figure out what "older clipboard methodology" they're using which we're apparently not supporting. Maybe they're setting a specific type of clipboard format (RTF? HTML?) that we're not looking for, but notepad++ can?

claunia commented

@mdrustad commented on GitHub (Nov 2, 2022):

On Nov 2, 2022, at 2:46 PM, Mike Griese @.***> wrote:

What application is running in the Terminal that you're pasting into?

It is an old IDE used for microcode development, maybe based on a very old visual studio? Anyway, very old.

How are you pasting (ctrl+shift+v, right mouse button, from the command palette...)/?

ctrl+shift+v, which does work after I copy from Notepad++. Which is able to accept the paste from the old app. That is what led me to report this on Terminal rather than grouse about the old program (there are always old programs).

Without knowing more about the application in question, I'm not sure how we'd be able to figure out what "older clipboard methodology" they're using which we're apparently not supporting. Maybe they're setting a specific type of clipboard format (RTF? HTML?) that we're not looking for, but notepad++ can?

It really can't be anything other than plain text. I know nothing about Windows development, so I can really only observe the difference in behavior between Terminal and Notepad++ for example.

--
Mark Rustad (he/him), Ethernet Products Group, Intel Corporation

@mdrustad commented on GitHub (Nov 2, 2022): > On Nov 2, 2022, at 2:46 PM, Mike Griese ***@***.***> wrote: > > What application is running in the Terminal that you're pasting into? It is an old IDE used for microcode development, maybe based on a very old visual studio? Anyway, very old. > How are you pasting (ctrl+shift+v, right mouse button, from the command palette...)/? ctrl+shift+v, which does work after I copy from Notepad++. Which is able to accept the paste from the old app. That is what led me to report this on Terminal rather than grouse about the old program (there are always old programs). > Without knowing more about the application in question, I'm not sure how we'd be able to figure out what "older clipboard methodology" they're using which we're apparently not supporting. Maybe they're setting a specific type of clipboard format (RTF? HTML?) that we're not looking for, but notepad++ can? It really can't be anything other than plain text. I know nothing about Windows development, so I can really only observe the difference in behavior between Terminal and Notepad++ for example. -- Mark Rustad (he/him), Ethernet Products Group, Intel Corporation

claunia commented

@mdrustad commented on GitHub (Nov 7, 2022):

On Nov 2, 2022, at 2:46 PM, Mike Griese @.***> wrote:

Without knowing more about the application in question, I'm not sure how we'd be able to figure out what "older clipboard methodology" they're using which we're apparently not supporting. Maybe they're setting a specific type of clipboard format (RTF? HTML?) that we're not looking for, but notepad++ can?

I had a thought on this. I'm sure that the old app predates UTF-8, which I expect any modern program to be using for text. The program is at least 20 years old, so UTF-8 really wasn't a thing back then. Presumably it would indicate some older encoding. ASCII or whatever PC standard was called (I used to at least know that).

A wild guess. Like I said, I know nothing about Windows apps, but it is a thought.

--
Mark Rustad (he/him), Ethernet Products Group, Intel Corporation

@mdrustad commented on GitHub (Nov 7, 2022): > On Nov 2, 2022, at 2:46 PM, Mike Griese ***@***.***> wrote: > > Without knowing more about the application in question, I'm not sure how we'd be able to figure out what "older clipboard methodology" they're using which we're apparently not supporting. Maybe they're setting a specific type of clipboard format (RTF? HTML?) that we're not looking for, but notepad++ can? I had a thought on this. I'm sure that the old app predates UTF-8, which I expect any modern program to be using for text. The program is at least 20 years old, so UTF-8 really wasn't a thing back then. Presumably it would indicate some older encoding. ASCII or whatever PC standard was called (I used to at least know that). A wild guess. Like I said, I know nothing about Windows apps, but it is a thought. -- Mark Rustad (he/him), Ethernet Products Group, Intel Corporation

claunia commented

@carlos-zamora commented on GitHub (Nov 7, 2022):

Our leading suspicion is #14129 but we can't be 100% sure. Since we're hoping to release a patch for this, we'll circle back and see if that fixes it.

@carlos-zamora commented on GitHub (Nov 7, 2022): Our leading suspicion is #14129 but we can't be 100% sure. Since we're hoping to release a patch for this, we'll circle back and see if that fixes it.

claunia commented

@mdrustad commented on GitHub (Nov 7, 2022):

On Nov 7, 2022, at 1:17 PM, Carlos Zamora @.***> wrote:

Our leading suspicion is #14129 but we can't be 100% sure. Since we're hoping to release a patch for this, we'll circle back and see if that fixes it.

I was going to say that it didn't seem t be related until I got to the part about uninitialized memory! Anyway, I tried the showkeys -a thing that was mentioned and it returned nothing when I pasted a clipbaord form that old app. Also, FWIW, it also won't paste into a Windows shell in Terminal, but I can into cmd.exe.

So unlikely related to bracketed paste, but possibly somehow related to uninitialized memory (since that could be most anything). Or not.

--
Mark Rustad (he/him), Ethernet Products Group, Intel Corporation

@mdrustad commented on GitHub (Nov 7, 2022): > On Nov 7, 2022, at 1:17 PM, Carlos Zamora ***@***.***> wrote: > > Our leading suspicion is #14129 but we can't be 100% sure. Since we're hoping to release a patch for this, we'll circle back and see if that fixes it. I was going to say that it didn't seem t be related until I got to the part about uninitialized memory! Anyway, I tried the showkeys -a thing that was mentioned and it returned nothing when I pasted a clipbaord form that old app. Also, FWIW, it also won't paste into a Windows shell in Terminal, but I can into cmd.exe. So unlikely related to bracketed paste, but possibly somehow related to uninitialized memory (since that could be most anything). Or not. -- Mark Rustad (he/him), Ethernet Products Group, Intel Corporation

claunia commented

a798a603e1/src/cascadia/TerminalApp/TerminalPage.cpp (L2173-L2176)

@zadjii-msft commented on GitHub (Nov 8, 2022):

Anyway, I tried the showkeys -a thing that was mentioned and it returned nothing when I pasted a clipbaord form that old app. Also, FWIW, it also won't paste into a Windows shell in Terminal, but I can into cmd.exe.

Well, shiz. That rules out the uninitialized memory one. Basically, whatever data is getting onto the clipboard, Terminal can't get out with

Clipboard.GetContent docs

I'm kinda lost at this point. Without the application that repros this, I don't know how we could possibly investigate more. Maybe a Feedback Hub trace, with the area being the "clipboard" might get more info, but I wouldn't know what part of that to dig through.

@zadjii-msft commented on GitHub (Nov 8, 2022): > Anyway, I tried the `showkeys -a` thing that was mentioned and it returned nothing when I pasted a clipbaord form that old app. Also, FWIW, it also won't paste into a Windows shell in Terminal, but I can into cmd.exe. Well, shiz. That rules out the uninitialized memory one. Basically, whatever data is getting onto the clipboard, Terminal can't get out with https://github.com/microsoft/terminal/blob/a798a603e1256b2823483b0459077df97ff0eb3a/src/cascadia/TerminalApp/TerminalPage.cpp#L2173-L2176 [`Clipboard.GetContent` docs](https://learn.microsoft.com/en-us/uwp/api/windows.applicationmodel.datatransfer.clipboard.getcontent?view=winrt-22621) I'm kinda lost at this point. Without the application that repros this, I don't know how we could possibly investigate more. Maybe a Feedback Hub trace, with the area being the "clipboard" might get more info, but I wouldn't know what part of that to dig through.

claunia commented

@zadjii-msft commented on GitHub (Nov 8, 2022):

We would basically need to know what the format of the clipboard content was, to be able to look for it. more docs.

Also curious: a798a603e1/src/interactivity/win32/Clipboard.cpp (L67-L72)

the vintage console (what you're thinking of when you think cmd.exe) is only ever looking for CF_UNICODETEXT, which I'm under the impression is the same as StandardDataFormats::Text()

@zadjii-msft commented on GitHub (Nov 8, 2022): We would basically need to know what the format of the clipboard content was, to be able to look for it. [more docs](https://learn.microsoft.com/en-us/uwp/api/Windows.ApplicationModel.DataTransfer.StandardDataFormats?view=winrt-22621#remarks). Also curious: https://github.com/microsoft/terminal/blob/a798a603e1256b2823483b0459077df97ff0eb3a/src/interactivity/win32/Clipboard.cpp#L67-L72 the vintage console (what you're thinking of when you think `cmd.exe`) is only ever looking for `CF_UNICODETEXT`, which I'm under the impression is the same as `StandardDataFormats::Text()`

claunia commented

@mdrustad commented on GitHub (Nov 8, 2022):

On Nov 8, 2022, at 7:56 AM, Mike Griese @.***> wrote:

the vintage console (what you're thinking of when you think cmd.exe) is only ever looking for CF_UNICODETEXT, which I'm under the impression is the same as StandardDataFormats::Text()

Maybe somewhere along the line the ability to convert 8-bit chars, ala ASCII, UTF-8, etc., into WCHAR was missed? It seems likely to be in the libraries somewhere. I don't know what is different between cmd and Terminal, but there should be a clue there as to what ingredient has the issue. It seems to me like Terminal would be using the newest stuff and newer is not always better.

Hmm. One other thing I should mention is that I am accessing this system via Remote Desktop from a Mac. Though in this case the copying and pasting is between two apps on the target, maybe the remote access has an effect on the clipboard somehow?

--
Mark Rustad (he/him), Ethernet Products Group, Intel Corporation

@mdrustad commented on GitHub (Nov 8, 2022): > On Nov 8, 2022, at 7:56 AM, Mike Griese ***@***.***> wrote: > > the vintage console (what you're thinking of when you think cmd.exe) is only ever looking for CF_UNICODETEXT, which I'm under the impression is the same as StandardDataFormats::Text() Maybe somewhere along the line the ability to convert 8-bit chars, ala ASCII, UTF-8, etc., into WCHAR was missed? It seems likely to be in the libraries somewhere. I don't know what is different between cmd and Terminal, but there should be a clue there as to what ingredient has the issue. It seems to me like Terminal would be using the newest stuff and newer is not always better. Hmm. One other thing I should mention is that I am accessing this system via Remote Desktop from a Mac. Though in this case the copying and pasting is between two apps on the target, maybe the remote access has an effect on the clipboard somehow? -- Mark Rustad (he/him), Ethernet Products Group, Intel Corporation

claunia commented

@zadjii-msft commented on GitHub (Nov 18, 2022):

accessing this system via Remote Desktop from a Mac

That certainly might have something to do with it! Some rudimentary googling suggests restarting rdpclip.exe. No idea if that would actually help, but the modern app platform has definitely taken dependencies on unexpected parts of the OS in the past.

@zadjii-msft commented on GitHub (Nov 18, 2022): > accessing this system via Remote Desktop from a Mac That certainly might have something to do with it! Some rudimentary googling suggests [restarting `rdpclip.exe`](http://woshub.com/cant-copy-paste-via-remote-desktop-rdp-clipboard/). No idea if that would actually help, but the modern app platform has definitely taken dependencies on unexpected parts of the OS in the past.

claunia commented

@mdrustad commented on GitHub (Nov 18, 2022):

Maybe, but I kind of doubt it. I can copy/paste between everything else successfully. It is just copying from that old workbench app into Terminal in the same system that doesn't work. Recall I can paste into Notepad++ in the same environment. It is only Terminal that has the problem. The regular command prompt also receives the paste just fine. All accessed via RDP on the same system.

@mdrustad commented on GitHub (Nov 18, 2022): Maybe, but I kind of doubt it. I can copy/paste between everything else successfully. It is just copying from that old workbench app into Terminal in the same system that doesn't work. Recall I can paste into Notepad++ in the same environment. It is only Terminal that has the problem. The regular command prompt also receives the paste just fine. All accessed via RDP on the same system.

claunia commented

@mdrustad commented on GitHub (Dec 12, 2022):

FWIW, I just tested this on a system without RDP involved and got the same result. I am unable to paste into Terminal that which was copied from a text window in that old IDE. The paste works fine in the traditional command prompt, Notepad++ and even Word. Only the new Terminal seems to have the problem.

@mdrustad commented on GitHub (Dec 12, 2022): FWIW, I just tested this on a system without RDP involved and got the same result. I am unable to paste into Terminal that which was copied from a text window in that old IDE. The paste works fine in the traditional command prompt, Notepad++ and even Word. Only the new Terminal seems to have the problem.

claunia commented

@zadjii-msft commented on GitHub (Dec 12, 2022):

Does pasting into any other UWP-like apps work? Something like... the builtin Mail or Calendar apps (I think they're UWPs). Sticky Notes might be a built-in UWP too. Any of those should be using the modern clipboard APIs.

I know it's an internal tool, but with the name of it, I might be able to search our internal bug database for issues, if any had been opened before.

Another theory - perhaps this internal tool is using EDP to try and protect the clipboard contents, and Terminal is either obeying / not obeying those APIs. I know that's something we added support to the console in the past, but I don't think we ever did anything for the Terminal.

@zadjii-msft commented on GitHub (Dec 12, 2022): Does pasting into any other UWP-like apps work? Something like... the builtin Mail or Calendar apps (I think they're UWPs). Sticky Notes might be a built-in UWP too. Any of those _should_ be using the modern clipboard APIs. I know it's an internal tool, but with the name of it, I might be able to search our internal bug database for issues, if any had been opened before. Another theory - perhaps this internal tool is using EDP to try and protect the clipboard contents, and Terminal is either obeying / not obeying those APIs. I know that's something we added support to the console in the past, but I don't think we ever did anything for the Terminal.

claunia commented

@zadjii-msft commented on GitHub (Dec 12, 2022):

Found on an internal thread

Clipboard does not support UTF-8. Apps are doing a workaround of using CF_UNICODETEXT and doing manual conversion from UTF-8 to UTF-16.

Interesting. I wonder if the tool you're using is setting the content as UTF-8,

... but honestly that doesn't sound right at all...

@zadjii-msft commented on GitHub (Dec 12, 2022): Found on an internal thread > Clipboard does not support UTF-8. Apps are doing a workaround of using CF_UNICODETEXT and doing manual conversion from UTF-8 to UTF-16. Interesting. I wonder if the tool you're using is setting the content as UTF-8, ... but honestly that doesn't sound right at all...

claunia commented

@zadjii-msft commented on GitHub (Dec 12, 2022):

From my contact on the Clipboard team:

We would need clipboard logs from feedback hub repro under the "Copy and Paste" node to diagnose.

They could try using free clipboard viewer to see what formats are placed on the clipboard:
Free Clipboard Viewer for Windows - Download

CAVEAT: This isn't an application from Microsoft. I honestly don't know how legit it is. But they did mention it has been used to view clipboard content since they have worked in the area

But if you file /feedback under "Copy and Paste", and share the aka.ms link here, I can make sure it gets in the right folks hands.

@zadjii-msft commented on GitHub (Dec 12, 2022): From my contact on the Clipboard team: > We would need clipboard logs from feedback hub repro under the "Copy and Paste" node to diagnose. > > They could try using free clipboard viewer to see what formats are placed on the clipboard: > [Free Clipboard Viewer for Windows - Download](https://freeclipboardviewer.com/) CAVEAT: This isn't an application from Microsoft. I honestly don't know how legit it is. But they did mention it has been used to view clipboard content since they have worked in the area But if you file /feedback under "Copy and Paste", and share the aka.ms link here, I can make sure it gets in the right folks hands.

claunia commented

@ghost commented on GitHub (Dec 12, 2022):

Hi there!

Can you please send us feedback with the Feedback Hub with this issue? Make sure to click the "Start recording" button, then reproduce the issue before submitting the feedback. Once it's submitted, paste the link here so we can more easily find your crash information on the back end?

Thanks!

@ghost commented on GitHub (Dec 12, 2022): Hi there! Can you please send us feedback with the [Feedback Hub](https://support.microsoft.com/en-us/windows/send-feedback-to-microsoft-with-the-feedback-hub-app-f59187f8-8739-22d6-ba93-f66612949332) with this issue? Make sure to click the "Start recording" button, then reproduce the issue before submitting the feedback. Once it's submitted, paste the link here so we can more easily find your crash information on the back end? Thanks! ![image](https://user-images.githubusercontent.com/18356694/140811502-a068f78b-89d2-4587-925a-73e19652b830.png) ![image](https://user-images.githubusercontent.com/18356694/140811557-cdc22a0f-fa6a-4f6a-953e-73b51f5548a3.png) ![image](https://user-images.githubusercontent.com/18221333/62478649-6de55400-b760-11e9-806e-5aab7e085a9f.png)

claunia commented

2026-01-31 06:25:00 +00:00

@mdrustad commented on GitHub (Dec 12, 2022):

Does pasting into any other UWP-like apps work? Something like... the builtin Mail or Calendar apps (I think they're UWPs). Sticky Notes might be a built-in UWP too. Any of those should be using the modern clipboard APIs.

I can confirm that it also doesn't work in Sticky Notes.

I know it's an internal tool, but with the name of it, I might be able to search our internal bug database for issues, if any had been opened before.

The name of it is "Developer Workbench".

Another theory - perhaps this internal tool is using EDP to try and protect the clipboard contents, and Terminal is either obeying / not obeying those APIs. I know that's something we added support to the console in the past, but I don't think we ever did anything for the Terminal.

I have no idea and no way to know.

I did run the Feedback Hub. The link is: https://aka.ms/AAj021g

@mdrustad commented on GitHub (Dec 12, 2022): > Does pasting into any other UWP-like apps work? Something like... the builtin Mail or Calendar apps (I think they're UWPs). Sticky Notes might be a built-in UWP too. Any of those _should_ be using the modern clipboard APIs. I can confirm that it also doesn't work in Sticky Notes. > I know it's an internal tool, but with the name of it, I might be able to search our internal bug database for issues, if any had been opened before. The name of it is "Developer Workbench". > Another theory - perhaps this internal tool is using EDP to try and protect the clipboard contents, and Terminal is either obeying / not obeying those APIs. I know that's something we added support to the console in the past, but I don't think we ever did anything for the Terminal. I have no idea and no way to know. I did run the Feedback Hub. The link is: https://aka.ms/AAj021g

claunia commented

@4nqyi commented on GitHub (Dec 24, 2022):

Subscribed since I’ve been having the same issue. If a block of text is already selected in the terminal this will remain in the clipboard (clip1) buffer even after selecting text from another application but only in the terminal clipboard (terminal1), so after you’ve copied (clip2) from another application and try to paste it to terminal1 you end up pasting the text from clip1.

Is there an option to clear the clipboard buffer if text is copied from another application? Putty clears the clipboard before copying form another application.

Windows Terminal Version: 1.15.3465.0

"copyOnSelect": true,

clipboard test
https://youtu.be/r2bklE0naT4

@4nqyi commented on GitHub (Dec 24, 2022): Subscribed since I’ve been having the same issue. If a block of text is already selected in the terminal this will remain in the clipboard (clip1) buffer even after selecting text from another application but only in the terminal clipboard (terminal1), so after you’ve copied (clip2) from another application and try to paste it to terminal1 you end up pasting the text from clip1. Is there an option to clear the clipboard buffer if text is copied from another application? Putty clears the clipboard before copying form another application. Windows Terminal Version: 1.15.3465.0 `"copyOnSelect": true,` clipboard test https://youtu.be/r2bklE0naT4

claunia commented

2026-01-31 06:25:00 +00:00

@mdrustad commented on GitHub (Dec 27, 2022):

Hmm. Your issue is different, though I have observed that behavior, as well. In my case there is no selection in Terminal to override the clipboard contents for the pastes that aren't working for me. I hadn't yet thought to complain about your issue because this other issue causes me much more grief.

@mdrustad commented on GitHub (Dec 27, 2022): Hmm. Your issue is different, though I have observed that behavior, as well. In my case there is no selection in Terminal to override the clipboard contents for the pastes that aren't working for me. I hadn't yet thought to complain about your issue because this other issue causes me much more grief.

claunia commented

2026-01-31 06:25:00 +00:00

@zadjii-msft commented on GitHub (Jan 5, 2023):

@4nqyi You're probably seeing the same thing as #14464 tbh

@zadjii-msft commented on GitHub (Jan 5, 2023): @4nqyi You're probably seeing the same thing as #14464 tbh

claunia commented

2026-01-31 06:25:01 +00:00

@zadjii-msft commented on GitHub (Jan 5, 2023):

Pre-emptively, did you make sure to capture the recording with the Feedback Hub when submitting feedback? I don't think I'd be able to do anything with the logs if they're there, BUT I'm also not seeing the normal kinds of logs attached. Again, maybe clipboard tracing is attached differently, but I'm guessing it didn't get attached 😞

@zadjii-msft commented on GitHub (Jan 5, 2023): Pre-emptively, did you make sure to capture the recording with the Feedback Hub when submitting feedback? I don't think I'd be able to do anything with the logs if they're there, BUT I'm also not seeing the normal kinds of logs attached. Again, maybe clipboard tracing is attached differently, but I'm guessing it didn't get attached 😞

claunia commented

2026-01-31 06:25:01 +00:00

@mdrustad commented on GitHub (Jan 5, 2023):

Like I said, I ran the Feedback Hub and it gave me this link: https://aka.ms/AAj021g

@mdrustad commented on GitHub (Jan 5, 2023): Like I said, I ran the Feedback Hub and it gave me this link: https://aka.ms/AAj021g

claunia commented

2026-01-31 06:25:01 +00:00

@ophers commented on GitHub (Jan 26, 2023):

I was going to open a new bug report but found this one.
I have the exact same behavior, except in my case it's not an "Old app" rather a WSLg window.

Reproducing:

I'm running Windows 11 with Microsoft store latest WSL - that includes WSLg.

I open Eclipse CDT (latest) from within a WSL terminal window (running CentOS 7).
I copy text from Eclipse.
Trying to paste to the WSL terminal window fails - nothing pasted.
Also nothing pasted to ANY Windows Terminal tab I open (CMD, Powershell, etc.),
neither to a new Terminal window I open.

But, it will paste to:

The find box of Windows Terminal
To a conhost.exe windows started from windows "Run" bar.
To Notepad

@ophers commented on GitHub (Jan 26, 2023): I was going to open a new bug report but found this one. I have the exact same behavior, except in my case it's not an "Old app" rather a WSLg window. ### Reproducing: I'm running Windows 11 with Microsoft store latest WSL - that includes WSLg. 1. I open Eclipse CDT (latest) from within a WSL terminal window (running CentOS 7). 2. I copy text from Eclipse. 3. Trying to paste to the WSL terminal window fails - nothing pasted. 4. Also nothing pasted to ANY Windows Terminal tab I open (CMD, Powershell, etc.), neither to a new Terminal window I open. #### But, it will paste to: 1. The find box of Windows Terminal ![image](https://user-images.githubusercontent.com/11839190/214826717-c09756f2-cae9-48b3-a162-79e42a2bba99.png) 2. To a `conhost.exe` windows started from windows "Run" bar. ![image](https://user-images.githubusercontent.com/11839190/214826991-5dcd9819-df97-45c5-aba6-861e99a03c31.png) 3. To `Notepad`

claunia commented

@RobMahn commented on GitHub (Feb 1, 2023):

I was having a similar issue with WSL and discovered that pasting text with a leading tab character, or even manually entering a tab key at the command prompt will crash the terminal. Ctl-C does not clear or recover. ^C is displayed, but no other keys are accepted. You must close this window and open another.

@RobMahn commented on GitHub (Feb 1, 2023): I was having a similar issue with WSL and discovered that pasting text with a leading tab character, or even manually entering a tab key at the command prompt will crash the terminal. Ctl-C does not clear or recover. ^C is displayed, but no other keys are accepted. You must close this window and open another.

claunia commented

@DHowett commented on GitHub (Feb 2, 2023):

I was having a similar issue with WSL and discovered that pasting text with a leading tab character, or even manually entering a tab key at the command prompt will crash the terminal. Ctl-C does not clear or recover. ^C is displayed, but no other keys are accepted. You must close this window and open another.

Turns out that's because tab completion in WSL is occasionally very slow. The tab character is just triggering tab completion. That's not a great experience though.

Your shell should be activating "bracketed paste mode" so that it doesn't attempt tab completion while you're pasting.

@DHowett commented on GitHub (Feb 2, 2023): > I was having a similar issue with WSL and discovered that pasting text with a leading tab character, or even manually entering a tab key at the command prompt will crash the terminal. Ctl-C does not clear or recover. ^C is displayed, but no other keys are accepted. You must close this window and open another. Turns out that's because _tab completion in WSL is occasionally very slow._ The tab character is just triggering tab completion. That's not a great experience though. Your shell should be activating "bracketed paste mode" so that it doesn't attempt tab completion while you're pasting.

claunia commented

@avih commented on GitHub (Sep 3, 2023):

Was the source of the issue identified?

I'm observing the same[*] issue where paste doesn't work when text is copied using win32 SetClipboardData(CF_UNICODETEXT, ...). Tested in Terminal versions 1.15 up to latest git master.

[*] Not exacty the same, because it seems sometimes it does paste after copy with SetClipboarData, but mostly it doesn't paste, and I don't know how to reproduce success/fail reliably.

For reference, here is a C program where pasting at the Windows terminal usually doesn't work after copying using e.g. clipw32 foobar - but it does paste elsewhere just fine, like in notepad, or in OpenConsole.exe which ships with the windows terminal. Compiled using mingw gcc in w64devkit.

clipw32.c

// compile using mingw: gcc -municode clipw32.c -o clipw32.exe

#include <stdio.h>
#include <windows.h>

int wmain(int argc, wchar_t **wargv)
{
    if (argc != 2) {
        fprintf(stderr, "Usage: clipw32 TEXT    Copy TEXT to clipboard\n");
        return 1;
    }

    int nbytes = sizeof(wchar_t) * (1 + wcslen(wargv[1]));
    void *data;
    HGLOBAL h;

    if (   (h = GlobalAlloc(GMEM_MOVEABLE, nbytes))
        && (data = GlobalLock(h))
        && memcpy(data, wargv[1], nbytes)
        && GlobalUnlock(h) == 0
        && OpenClipboard(NULL)
        && SetClipboardData(CF_UNICODETEXT, h))
    {
        CloseClipboard();
        return 0;
    }

    fprintf(stderr, "clipw32: copy failed: %u\n", GetLastError());
    return 1;
}

In contrast, this is a similar program in dotnet which copies using Clipboard.SetText(s), where paste at the terminal seem to always succeed after copying using e.g. clipnet hello:

clipnet.cs

class Program {
    [System.STAThreadAttribute]
    static int Main(string[] args) {
        if (args.Length == 1) {
            System.Windows.Forms.Clipboard.SetText(args[0]);
            return 0;
        }
        System.Console.Error.Write
            ("Usage: clipnet TEXT    Copy TEXT to clipboard\n");
        return 1;
    }
}

@avih commented on GitHub (Sep 3, 2023): Was the source of the issue identified? I'm observing the same[*] issue where paste doesn't work when text is copied using win32 `SetClipboardData(CF_UNICODETEXT, ...)`. Tested in Terminal versions 1.15 up to latest git master. [*] Not exacty the same, because it seems sometimes it does paste after copy with `SetClipboarData`, but mostly it doesn't paste, and I don't know how to reproduce success/fail reliably. For reference, here is a C program where pasting at the Windows terminal usually doesn't work after copying using e.g. `clipw32 foobar` - but it does paste elsewhere just fine, like in notepad, or in `OpenConsole.exe` which ships with the windows terminal. Compiled using mingw gcc in [w64devkit](https://github.com/skeeto/w64devkit). <details> <summary>clipw32.c</summary> ```c // compile using mingw: gcc -municode clipw32.c -o clipw32.exe #include <stdio.h> #include <windows.h> int wmain(int argc, wchar_t **wargv) { if (argc != 2) { fprintf(stderr, "Usage: clipw32 TEXT Copy TEXT to clipboard\n"); return 1; } int nbytes = sizeof(wchar_t) * (1 + wcslen(wargv[1])); void *data; HGLOBAL h; if ( (h = GlobalAlloc(GMEM_MOVEABLE, nbytes)) && (data = GlobalLock(h)) && memcpy(data, wargv[1], nbytes) && GlobalUnlock(h) == 0 && OpenClipboard(NULL) && SetClipboardData(CF_UNICODETEXT, h)) { CloseClipboard(); return 0; } fprintf(stderr, "clipw32: copy failed: %u\n", GetLastError()); return 1; } ``` </details> In contrast, this is a similar program in dotnet which copies using `Clipboard.SetText(s)`, where paste at the terminal seem to always succeed after copying using e.g. `clipnet hello`: <details> <summary>clipnet.cs</summary> ```cs class Program { [System.STAThreadAttribute] static int Main(string[] args) { if (args.Length == 1) { System.Windows.Forms.Clipboard.SetText(args[0]); return 0; } System.Console.Error.Write ("Usage: clipnet TEXT Copy TEXT to clipboard\n"); return 1; } } ``` </details>

claunia commented