Make `wl-paste --watch` handle slow commands better

[e00E]

wl-clipboard 2.0.0 from arch linux package

wl-paste behaves problematically if the watch command is slow.

Terminal 1: wl-paste --watch bash -c "xargs -I{} echo {};" Terminal 2: wl-copy 0; sleep 0.1; wl-copy 1; sleep 0.1; wl-copy 2; sleep 0.1; wl-copy 3; Output of terminal 1: 0 1 2 3

This is as expected.

Terminal 1: wl-paste --watch bash -c "sleep 1; xargs -I{} echo {};" Terminal 2: wl-copy 0; sleep 0.1; wl-copy 1; sleep 0.1; wl-copy 2; sleep 0.1; wl-copy 3; Output of terminal 1: 0 3

Now that the command is slow (by sleeping for 1 second) the intermediate numbers are not observed.

Note that even in the first example we need to sleep 0.1 between wl-copy or not all numbers will be observed. It is unclear to me whether this is a bug in wl-clipboard or a limitation of wayland.

It would be better to not miss clipboard changes due to the command being slow. The command could be executed in the background without blocking the next command.

[bugaevc]

Hi!

It is unclear to me whether this is a bug in wl-clipboard or a limitation of wayland. It would be better to not miss clipboard changes due to the command being slow. The command could be executed in the background without blocking the next command.

It's not exactly a bug, it's an "issue" at most. As you say, it would be better not to miss changes while the command is running, and run the command in the background in order to achieve that. See also:

https://github.com/bugaevc/wl-clipboard/blob/2c3cee1c8173d75b1411997b2c0f3e486194ac0c/src/types/copy-action.c#L86-L92

By the way, is there any reason you use xargs -I{} echo {}; instead of a simple xargs or just cat?

[e00E]

No technical reason. I had a more complicated command that I was passing the clipboard content to so for this issue I reduced it to echo without thinking about reducing the xargs part too.