Add 'wait' option to timeout x msec after last paste event

[astrand]

My passwordmanager used 'xclip -l 1 -quiet' to put the username (and after exiting) the password on the clipboard for the browser to read.

New browsers generate a multitude of paste events for one paste. -l 1 is not useful, and since the number of paste events needed for one paste differs between applications, I thought of something else.

This patch implements -wait (or -w). Eg: 'xclip -w 500 -quiet', this waits indefinately for the first paste event, after that it waits 500 msec for the next one. If the timer expires, xclip exits.

Reported by: rikatsneldotit

Original Ticket: xclip/patches/6

[astrand]

Ah, what a pain modern systems are. I hate to be that guy, but xclip doesn't use many resources, and exits as soon something else takes the clipboard, so what's wrong with just letting it run? Can you patch your password manager to just run "xclip"?

Original comment by: kousu

[astrand]

The problem is that my passwordmanager needs to know when to put the password on the clipboard. I don't want to paste my username and then tell my passwordmanager to put the password on the clipboard and then paste my password; it should just be paste-paste.

Since "put the password on the clipboard after n paste events" does not work, I implemented this timeout. So my passwordmanager can use "put the password on the clipboard n ms after the first paste event".

Original comment by: rikatsneldotit