`jobs -p' should be read into an array, as it might contain more than
one job.
[cdown: squash, massage changelog, remove space between local/readarray]
Since trapping a signal breaks `wait $_CM_CLIPNOTIFY_PID` w/o killing
the clipnotify job, call kill_background_jobs before restarting the
loop. This prevents `clipctl enable` from spawning another job.
This allows avoiding having to delete after the fact for things like
issues #57 and #98.
Why have this over just stopping clipmenud? Well:
1. Stopping clipmenud should usually be an init system action, but we
are init-system agnostic. If we just exit, we don't have a way of
reliably starting again.
2. Even if we *do* do it using the init system, we don't want some
things (like a lingering xsel which owns the selection for
CM_OWN_CLIPBOARD) being killed as well.
3. This is a nicer interface for things like password managers to stop
clipmenu rather than stopping clipmenu entirely.
In c7c894a0, a per-selection line-cache was introduced in order to
overcome some of the limitations of clipmenu at the time (for example,
missing duplicate detection). However, now we have all the features we
need to have a single line cache again, and having multiple line caches
has caused more trouble than it is worth.
For example, maintaining CM_MAX_CLIPS globally is extremely cumbersome,
so we don't do it, and CM_MAX_CLIPS is actually acted on per-selection.
We also have had bugs where we perform actions on cache files without
properly consulting other line caches, and while those can be fixed, the
simplest thing to do now is just to go back to having a single line
cache.
The clipboard does not get recorded when the title of the currently active
window matches the regular expression in CM_IGNORE_WINDOW. This allows copying
passwords from a password manager without the passwords ending up in clipmenu.
The matching is not 100% exact however, as there is a race condition between the
time the clipboard is populated, clipmenu queries the clipboard, and the active
window gets queried. This race condition can be especially problematic when
using polling with large intervals instead of clipnotify.
