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.
It was deleting the file before the partial selection because
`last_filename` was saved before filename was actually ready (so was
actually saving the one before the last).
Fixes#75.
Fixes#67. This used to be useful in order to avoid doing multiple
writes back when we didn't deduplicate in clipmenu client, but now we do
and don't need this. Even more impressively, it actually breaks things!
See #67 for more information.
