[Cmd] use prompt-toolkit native clipboard integration

[neoniobium]

Addresses #1720

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.59%. Comparing base (85c0c2d) to head (ffae287).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1721      +/-   ##
==========================================
- Coverage   99.61%   99.59%   -0.02%     
==========================================
  Files          23       22       -1     
  Lines        5915     5931      +16     
==========================================
+ Hits         5892     5907      +15     
- Misses         23       24       +1     

Flag	Coverage Δ
unittests	99.59% <100.00%> (-0.02%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

[tleonhardt]

@neoniobium You'll need to merge master into your branch.

Btw, you should now be able to create branches in the main repo, so you don't need to use a Fork anymore unless you want to. Using branches in main repo, makes it easier for others to help collaborate.

[neoniobium]

@neoniobium You'll need to merge master into your branch.

Btw, you should now be able to create branches in the main repo, so you don't need to use a Fork anymore unless you want to. Using branches in main repo, makes it easier for others to help collaborate.

Ok, next time I will create a branch instead of using my frok.

[neoniobium]

Thanks again for the review.

I was also thinking whether the clipboard should be shared will each session, or example read_secret. I think good arguments for either case. I would like to know your opinion on that point.

Furthermore I was wondering allow_clipboard is still a good variable name since is now allow a clipboard available.

[tleonhardt]

@kmvanbrunt Do you have any thoughts on this PR?

[tleonhardt]

@neoniobium I pushed an update to your branch that merged in changes from main.

[tleonhardt]

@neoniobium At a high-level glance this PR seems like it makes what was a very simple feature much more complicated.

After having time to step away and reflect after a vacation, I'm not sure I see the benefit. If it entirely removed the dependency on pyperclip to replace it with one on prompt-toolkit (which we would need regardless), I would understand the motivation. But it doesn't remove the dependency on pyperclip.

Are there benefits I'm missing? If not, I think we should just cancel it and leave things the way they are.

[tleonhardt]

Potential crash if stdout stream operations fail.

If self.stdout was closed during command execution, calling self.stdout.seek(0) or self.stdout.read() will raise an exception. Since these calls are outside the inner try...except block, the exception will propagate out of the command loop and could crash the application instead of being cleanly reported as a ClipboardError

This should be moved within the inner try..except block below.

[kmvanbrunt]

I have a few concerns with this.

1. It is making simple code more complex.
2. By falling back to prompt-toolkit's in-memory clipboard, it is silently failing. The user will have no idea why nothing is being written to their system's clipboard. Currently if a user is missing a dependency like xclip, we display this pyperclip exception when they try to use the clipboard.

PyperclipException: Pyperclip could not find a copy/paste mechanism for your system. For more information,
please visit https://pyperclip.readthedocs.io/en/latest/index.html#not-implemented-error
On Linux, you can run `sudo apt-get install xclip`, `sudo apt-get install xselect` (on X11) or
`sudo apt-get install wl-clipboard` (on Wayland) to install a copy/paste mechanism.

[neoniobium]

My interest in using the prompt-toolkit clipboard implementation does not come from improving the existing redirection feature, but rather from using the system clipboard for all clipboard interactions at least for the app's main session if specified.

Currently, each session has its own in-memory clipboard. While this is not explicitly used by cmd2, it can, in principle, be accessed by a developer who wishes to implement any clipboard related feature. This could be a command-line option interacting with the clipboard, or shortcuts that are similar or closely related to vi-mode-like features.

A developer might expect that the allow_clipboard option would make all sessions use the system clipboard for in-app clipboard interactions. In my opinion, "disable clipboard interactions" is now an ambiguous phrasing, since there is always some kind of clipboard available for each session.

Whist, this is currently not the case. If the system clipboard is accessible to cmd2 via pyperclip, the redirection feature could still acccesable within the app by utilizing the in-memory clipboard instead. This PR was however not intended to do this.

I am fine with closing this PR if you think the increased complexity outweighs the potential benefits.

[tleonhardt]

@neoniobium Are there other clipboard interactions beyond those currently supported by cmd2 that you think it would be useful for cmd2 to support?

I'd like to better understand your envisioned use case(s).

[neoniobium]

Currently, using C-y to yank into the terminal is supported and captured by a cmd2 app, but it uses an in-memory clipboard that is separate for each session. Deleting characters from the current command via C-w, C-u, etc., and pasting them back into the terminal by pressing C-y is supported in the same way.

Pasting from the system clipboard using C-y or copying deleted characters to it (via C-w, C-u, etc.) is currently not supported. However, it would become the default behavior with the implementation in this PR. This might actually be unexpected for a user, since it is not the out-of-the-box behavior for most terminals, even though it can often be configured. With this PR, cmd2's redirection feature would also share the same clipboard with C-y, C-w, etc.—and I am not sure what a new user would expect here.

After contrasting this behavior with the defaults of most terminals, I think using the system clipboard for all of these interactions—controlled only by a single option and changing the defaults at once is not a good idea. When filing this PR, I was under the assumption that the behavior proposed here (aside from cmd2's own redirection feature) was the default for most terminals when setting the clipboard. But as I see it now, I am simply the one who has grown adjusted to using odd defaults.

Hence, I will close this PR.