Workaround for reversed right click paste

[Tadas]

Fixes #496

Not sure if this is the correct way to detect right click, but I found the same method in https://github.com/lzybkr/PSReadLine/blob/9d592b875ebea83d6385b9cc6b6899584b08277a/PSReadLine/BasicEditing.cs#L246-L249

[lzybkr]

Thanks for the PR.

There is no reliable way I know of to detect paste - we must use a heuristic.

I'm not sure this is the best approach. I think the right fix to this issue will also fix #37 and #77, maybe #245 and possibly others.

What I'd planned was to implement a stronger heuristic that measures the time between keys and makes assumptions about how fast a human can type - and if that rate is greatly exceeded, collect all of the keys and do a single paste operation, hopefully the same as though the user used Ctrl+V.

I guess there are a few patterns where a key is obviously not something pasted - e.g. when Alt is specified, and probably some with Ctrl, though some keys with Ctrl set could be pasted, so it's not a clear cut.

[Tadas]

Ah the pleasures of conhost :) Looking at how fast the keys are coming in might actually be a workable solution. Alternatively, have you thought about getting a hold of the mouse events? It seems to be possible

Let's close this in favour of a more robust solution.

[lzybkr]

I hadn't considered reading mouse events for this issue - but reading those does require not using Console.ReadKey, which means duplicating all of that code. I know this because I investigated detecting resize events.

That said, it's not clear to me that the right click event will be available - and even if it is, that doesn't help if the user types Alt+Space,e,p to paste.

[lzybkr]

I opened #579 to track all of the right click paste issues - and I think they are all addressable without this PR so I'm closing.