+1 I'd be willing to pay >another $30 on top of my existing Legendary license for
unlimited clipboard history, and I'd fully accept any CPU/Memory hit necessary to get it.
I use Clipboard History as a general buffer for everything in my life,
and losing everything beyond 3 months is a frequent source of headache.
Here's a small sample of a few recent things I've lost due to history expiring:
flight confirmation details
commit summaries with commit ids (detached commits that are hard to find due to deleted branches)
ssh public keys
many many many file paths (lots of obscure config file paths that I never bother to remember)
entire config files
blog post drafts
comments on social media
form fields on websites
It's always stuff that I don't realize at the time would be important later
so it would be pointless to try and use snippets for most of these.
Having a massive index of every meaningful string that's passed through my
brain is incredibly useful. If needed you could hide "6 months" "12 months" and "unlimited" behind an
"Advanced settings" pane and display a big warning about potential performance
For now I just periodically back up `~/Library/Application\ Support/Alfred/Databases/clipboard.alfdb`
to a separate folder, and merge the rows in it with a main database. This at
least allows me to query further back by querying the merged database directly.
Maybe I'll build a workflow to do that if I have time, but no promises.
I've created a script that handles the backup of the db, merging it with an
infinite-history sqlite db in my home folder, and searching functionality.
/* Delete any items that are the same in both databases */
DELETE FROM merged_db.clipboard
SELECT 1 FROM latest_db.clipboard latest
/* Insert all items from the latest_db backup */
INSERT INTO merged_db.clipboard
SELECT * FROM latest_db.clipboard;
Full source: alfred-clipboard.sh (it's a fully functional infinite-history solution for Alfred, with backup, search, exporting, etc.)
One thing I want to try is periodically overwriting the Alfred internal db with my merged one,
and translating all the older timestamps so that they're artificially set to something within the last 3 months,
that way I can accumulate infinite history without Alfred attempting to expire anything.
In theory it should work fine, I'll probably update my script to do that sometime in the next week.
One thing I cant figure out though is the format of the timestamps (e.g. `584601195`), they're not valid UNIX timestamps,
they must be offsets in seconds from some custom hardcoded date.
When I tried prepending `1` to make it something like `1584601195`, it becomes a valid
unix timestamp, but the time is ~4 months in the future! If anyone has more info on the schema, let me know.
I also tried hacking around the limit by changing the Alfred binary directly
but unfortunately I was only able to find the limit in the .nib file (which
is useless as it's just the GUI definition).
I'd have to properly decompile Alfred it to find the actual limit logic...
$ ggrep --byte-offset --only-matching --text '3 Months' \
'/Applications/Alfred 3.app/Contents/Frameworks/Alfred Framework.framework/Versions/A/Resources/AlfredFeatureClipboard.nib'
(Now I just have to convince the Google Chrome team to also allow storing
browser history longer than 3 months... then the two biggest sources of
data-loss pain in my life will be eliminated).