Clipboard managers aren't able to insert text

[nickjj]

Hey,

Windows 10 has a built in clipboard manager that lets you manage multiple clipboard items. There's also better clipboard managers such as the Ditto tool. It lets you search, retrieve and paste in clipboard items copied in the past.

In both cases, when you try to insert text into wsltty using them, you wind up with either no output (it's like the terminal absorbs the output) or you get literally ^V as output depending on how you decide to insert the text (through a hotkey or clicking the clipboard item with the mouse). I'm guessing it's because these tools send CTRL + V in the case where ^V ends up as the output.

Is there any way this can be worked around without patching the clipboard manager tool? Most of them aren't open source (although Ditto is), so that's not really possible anyways.

[mintty]

Duplicate of #139; this has been fixed in 1.9.6 already, at least for the Windows clipboard history.
Which version do you run? Please check whether the fix also works for Ditto.

[mintty]

What's the purpose of that crazy tool, actually? It seems to be able to paste into one application only, not the current foreground window.

[mintty]

These tools send two keyboard events to the target application: Control and V.
Windows clipboard history sends the V at least in a way that can be distinguished from a true V: it does not send a "scancode" (it's 0 in the message), so a workaround could be applied for it.
If the key messages are indistinguishable from "native" keyboard input, it is impossible for an application to handle this case. It's a Ditto bug.

[nickjj]

I am using 1.9.6 according to the About menu. Ditto does not work (it fails with the description supplied in the issue).

The purpose of the tool allows you to save a history of your clipboard and then be able to search through it and paste an item from that history into any window you want. It saves a lot of time. It pastes the item into the current foreground window just like if you press CTRL + V into the current foreground window.

Ditto works in every other application on Windows except for wsltty (and also ubuntu.exe too).

[mintty]

My question about its purpose should address the issue that Ditto, by default, only pastes into the same application that copied text to the clipboard before. That's a restriction I'd normally not expect from a clipboard.

Anyway, about the pasting: I've explained above why it does not work; note that a terminal cannot simply interpret Control+V as Paste because Control+V is a perfectly valid terminal input, a control character, that terminal users expect to be available.

The workaround mintty applies for the Windows clipboard history would apply if Ditto sent its key events in the same way. Please report that as an issue to Ditto.

[nickjj]

My question about its purpose should address the issue that Ditto, by default, only pastes into the same application that copied text to the clipboard before. That's a restriction I'd normally not expect from a clipboard.

Ditto isn't limited like that. If I copy text from this Github issue textarea, it gets placed into Ditto's multi-clipboard manager and then I can paste it into my IRC client, notepad, VSCode, Emacs or anything else.

It works just like the normal clipboard in that regard, except it gives you multiple items that you can search through and pick. It's comparable to the Windows 10 clipboard manager except it's a lot better (searchable history which is essential, allows you to strip formatting, etc.).

Is there no way to allow mintty to accept CTRL + V as a paste action as an option or registry hack?

Ditto's source code is available at https://sourceforge.net/p/ditto-cp/ditto/ci/master/tree/, but what exactly would I report as a bug? I don't know C but it looks like it uses VK_* key codes. In its advanced options it uses ^{VKEY86} as the "default paste string". Do you happen to know what the correct string would be for CTRL + Shift + V? I'm guessing ^ is CTRL, 86 is V. Shift is the missing link.

[nickjj]

I figured it out. I set ^+{VKEY86} as the paste string and now it works, but of course it only works inside of the terminal since CTRL + Shift + V doesn't work for pasting in other Windows apps.

This seems like the only answer is to change the terminal to accept CTRL + V (as an option) but it sounds like you won't do that so I'll close this.

[mintty]

^+{VKEY86}

How did you find that solution and where do you configure it in Ditto?

[nickjj]

I brute forced it. I looked at the keyboard and then thought long and hard on what type of symbols I've seen in the past to identify CTRL, Shift and ALT keys. The first one that came to mind was +, and it worked.

It's in the advanced options under general settings. It's the "default paste string".

The only problem is not all apps support that paste code. Fortunately browsers allow ctrl + shift + V to paste. Between the browser and the terminal environment that's where I spend 99% of my time. For apps that don't accept it, the normal Windows ctrl + V would work (bypassing Ditto completely).

[mintty]

See also option CtrlExchangeShift and issue mintty/mintty#817.

[nickjj]

Thanks, but I guess in that case, if you set CtrlExchangeShift=yes then CTRL + C would copy text instead of killing a foreground process?

[mintty]

Yes, that's why I was very hesitant against introducing that option (as seen in the referred and further issues). But using the user-definable keys feature, you could actually setup mintty to keep Control+C and remap Control+V to paste.
Maybe I'll report an issue to Ditto; it's not necessary to check the code and deliver a solution already to do that.