Micro: Allow enabling/disabling system clipboard synchronization in config/commands

[CosmicToast]

Description of the problem or steps to reproduce

1. Be in a gnome wayland session (I don't know which of these is relevant).
2. Open file in micro.
3. Press the CutLine keybind (tested with the default ^k but also &x).
4. Something (unknown) briefly pops up (the terminal and the window descriptor in the top-left flash, and a new application seems to temporarily show up in the launcher if it's visible).

Specifications

Commit hash: 60846f54
OS: Fedora 32
Terminal: gnome-terminal

[zyedidia]

The CutLine action copies text to the clipboard and to do that it launches wl-copy. Does this occur when copying to the clipboard with similar applications or directly with wl-copy?

[CosmicToast]

Does this occur when copying to the clipboard with similar applications or directly with wl-copy?

Oh, I hadn't realized that micro grew support for wl-copy.
Looks like it occurs (though to a lesser extent) when just piping something into wl-copy as well - I just hadn't noticed it because (unlike with CutLine) I don't normally invoke it multiple times in a row.

Consequently, it would be nice to be able to turn off system clipboard synchronization in the config (and/or be able to turn it on/off dynamically via a command).
Specifically system sync so that CutLine still works within micro itself.

I'll ask the wl-clipboard project on clarifications re: this behavior once I have time (likely this weekend).

[CosmicToast]

To update:

1. This is a wl-clipboard workaround for mutter not implementing a common interface.
2. Mutter wants consumers to use their own clipboard manager, rather than things like wl-clipboard (though it's not entirely clear to me by just looking at the MR as to how a consumer might use it, see here).

Consequently, looks like the options are:
a) make the behaviour (of using wl-clipboard) toggle-able / configure-able
b) add support for mutter's clipboard manager (assuming one can figure it out)

[zyedidia]

I think I will address this with new clipboard functionality and an option to configure it. I have recently discovered the "OSC 52" escape sequence which can be used for terminal applications to copy to clipboard (for details, see https://github.com/tmux/tmux/wiki/Clipboard). I'll then add an option that can configure how the clipboard should work (it will have values like internal, xclip (which would use wl-clipboard on wayland), osc52, although I'm still not sure about the naming for these values). I'm also not sure if the default should be the xclip type, or OSC 52, since OSC 52 is not supported in VTE terminals such as Gnome-terminal. However, OSC52 would allow micro's copy-paste to work seamlessly over ssh, which is a big deal to a lot of people.

[CosmicToast]

Ideally one would also be able to toggle it in runtime (e.g something like > setclipboard xclip, e.g I would disable it by default (no OSC 52 in gnome-terminal), but would have the ability to turn it on temporarily in case I want to copy something without relaunching micro).

over ssh

One of the reasons I adopted micro in the first place is because I can make my own static builds of it to arbitrarily copy/drop into random servers I ssh to (I work as an admin) - to get a consistent editing experience.
That would indeed be a great option to have!

default

tmux is seemingly able to detect capabilities relating to OSC 52, so perhaps OSC 52 should be the default, unless it's not present, in which case fall back to either xclip or internal?

[zyedidia]

I have just added support for OSC 52, and clipboard configuration via the clipboard option. The possible values are external (xclip, etc..), terminal (OSC 52), and internal. It can be changed at runtime (> set clipboard external). Unfortunately I wasn't able to find any good way to detect if a terminal supports OSC 52, so I will leave it up to the user to enable the option manually (default is external).

See the commit and relevant documentation (> help options, > help copypaste) for more details.