Fixes #2205. Reduce fragility of clipboard related unit tests

[tig]

Fixes #2205

[tig]

Windows tests, before:

Windows tests, after:

So not significantly faster (was hoping that as a side benefit).

[tig]

Before on Debian:

After on Debian:

SIGNIFICANTLY FASTER

[tig]

@BDisp - Man, I feel your pain. The Clipboard on WSL and Linux is a mysterious beast!

I think I made solid progress in making the unit tests more robust with this PR. Please review.

@tznind, @BDisp (or anyone else) - please pull this down locally on a Mac AND real Linux install and test it please. I don't have either.

[tznind]

Can confirm that running Ubuntu laptop things work as expected.

Distributor ID:	Ubuntu
Description:	Ubuntu 20.04.4 LTS
Release:	20.04
Codename:	focal

I was able to copy/paste when xclip was installed. When it was not installed I was unable to copy and when I try to paste I get the text 'Clipboard Not Supported'.

[tig]

Alright, I think I have everything fixed except the Curses reset issue @BDisp noted.

Still trying to figure that one out...

[tig]

As a developer it would be nice if it were easy to tailor the libraries behaviour under such circumstances e.g. instead of outputting "Clipboard not available" it could:

• Output nothing at all
• Copy/Paste from an internal 'memory only' clipboard class
• Display a modal dialog telling my users to install xclip (if on linux)

This is the correct behavior, IMO, and I just fixed a stupid mistake that makes it work this way (which is how it worked before):

• Copy/Paste from an internal 'memory only' clipboard class

[BDisp]

Alright, I think I have everything fixed except the Curses reset issue @BDisp noted.

Still trying to figure that one out...

One that is occur to me is any exception when is thrown deviates the execution of the reset.

[BDisp]

Alright, I think I have everything fixed except the Curses reset issue @BDisp noted.

Still trying to figure that one out...

It seems to be fixed now. Perhaps some Windows 11 update, don't know.

[tig]

Curses is still acting weird, but at least I got my VS2022/Windows Terminal config working again. The WT team got me a private build with a fix and I'm now unblocked.

[tig]

@BDisp - I cannot get breakpoints to hit when debugging in WSL on two different machines.

I have searched high and low and cannot find out what I'm doing wrong or have mis-configured.

Do you have any suggestions on what I can try?

I can't finish this PR until I fix the bug I caused in the TextView/Editor scenario where copy/paste operations corrupt curses. And I can't figure out what's going on without being able to debug!

Gracias for any help you can provide!

The bug shows itself in many scenarios, not just Editor For example Notepad:

[tig]

Oh, and a clue to why VS WSL debugging isn't working is this, shown after I end a WSL debug session:

The target process exited without raising a CoreCLR started event. Ensure that the target process is configured to use .NET Core. This may be expected if the target process did not run on .NET Core.
The program '[2440] wsl.exe' has exited with code 0 (0x0).

[BDisp]

The easiest way to debug CursesDriver in the Visual Studio 2022 is run with WSL2 selector and attach it to process. Place the breakpoints where you want and voila.

[BDisp]

@tig this issue is already in the current develop branch. Will another PR caused this or some Windows update?

[tig]

@BDisp & @tznind if you struggle with this too, please upvote this
https://developercommunity.visualstudio.com/t/Debugging-dotnet-console-apps-in-VS2022/10242732?port=1025&fsid=11a4c115-97a0-4e4e-b986-b9a89b2838d7&ref=native&refTime=1672699586507&refUserId=5a90c5f2-d9f6-6a3a-8715-c058b3fda1aa

[tig]

@tig this issue is already in the current develop branch. Will another PR caused this or some Windows update?

I see other oddities in develop when using the clipboard in the Editor scenario under WSL, but not screen corruption.

What, specifically, is the issue you see?

(Nevermind, I see you are referring to the Notepad issue:

I DO see this in develop.)

(And of course, now that I'm trying to get new video of the Editor bug I think I caused, it no longer repros. Sigh.)

[BDisp]

@BDisp & @tznind if you struggle with this too, please upvote this https://developercommunity.visualstudio.com/t/Debugging-dotnet-console-apps-in-VS2022/10242732?port=1025&fsid=11a4c115-97a0-4e4e-b986-b9a89b2838d7&ref=native&refTime=1672699586507&refUserId=5a90c5f2-d9f6-6a3a-8715-c058b3fda1aa

The correct link for others users is only https://developercommunity.visualstudio.com/t/Debugging-dotnet-console-apps-in-VS2022/10242732, otherwise we receive this warning:

[tig]

Based on the fact I can no longer reproduce the Editor issue where curses gets corrupted with this PR, I'm going to merge it. The benefits of all the work I did far outweigh an issue that is so hard to repo on WSL.

If it repos again, we'll just open another issue for it.