Use the OS clipboard only for explicit cut/copy/paste operations

[Tastaturtaste]

This PR addresses #759.

This PR reverts most commands to using the local cut buffer for cut/copy/paste operations except for CutSelection and CopySelection. Those two commands now have a parameter to specify which clipboard to use. Current keybindings for those commands (CutSelection: Ctrl+Shift+X, CopySelection: Ctrl+Shift+V) still use the system clipboard. Currently, no keybindings are defaulted for these commands and the cut buffer.

We can't statically compile everything related to the system_clipboard feature out, as that would include the parametrized commands mentioned above. Activating the feature would not be purely additive anymore. Therefore those parameters have to stay even when the feature is disabled and the commands have to do something when the feature is not enabled. Currently, there is no facility in place for EditCommands to fail in a recoverable manner or indicate failure to the user. A few possibilities how to handle this situation that come to mind:

1. Panic if the OS clipboard would have to be used. The user of the crate would be responsible to ensure commands using the OS clipboard are only used when the feature is enabled.
2. Silently do nothing when the OS clipboard would have to be used
3. Silently use the local clipboard, even when the command explicitly requests the OS clipboard

Of these options, I currently implement panicking. I think it is the least surprising thing to do for users of reedline. Requesting to use the OS clipboard while not having system_clipboard enabled is surely a logic bug. But I am open to discussion if someone sees it another way.

The changes can be used with this nushell branch, where I use this reedline branch to test things out.

[sholderbach]

Thanks for the quick turnaround!

Looks good apart from how we should handle the case if the feature is not enabled.

[sholderbach]

From the "don't panic" Nushell side this is a dangerous panic footgun.

EditCommand::Paste { system_clipboard: true } provides a possibly more aesthetic API over separate variants. But if you were to compile without system_clipboard and pass the same event this could panic the shell.

reedline/src/core_editor/editor.rs

Lines 132 to 137 in 998a2f7

	EditCommand::Paste {
	system_clipboard: true,
	} => self.paste_system_clipboard(),
	EditCommand::Paste {
	system_clipboard: false,
	} => self.paste_cut_buffer(),

The match compiles either way. This would require extra care while parsing complex user configs.

Either we completely restrict it at compile time via separate variants or turn it into something handlable.

[Tastaturtaste]

I assume turning it into something handlable would involve returning a Result up the call stack so nushell can do something like inform the user? In general I think that might be a good idea, it also opens up for other failable commands should the need arise. Though I don't know if that is the right approach for handling this specific issue. What is your opinion on it? How should it be handled?

[sholderbach]

Let's keep it simple for now. As the problem only arises in connection with the choice of flags, we can keep those in separate variants that are cfged themelves.
If a library user provides the flag they can configure reedline to their pleasing but if they choose not to they don't get the added complexity.

[sholderbach]

Thanks for championing this! Let's get this moving.

[Tastaturtaste]

Ok, that was fast :D

If you want to give it a try: https://github.com/Tastaturtaste/nushell/tree/bug/11907-system-clipboard-not-for-everything

[fdncred]

Thanks again @Tastaturtaste.