Jump to content


  • Content Count

  • Joined

  • Last visited

Posts posted by theSquashSH

  1. I think you can solve that by issuing an exclusive lock on the db while modifying it:

    PRAGMA locking_mode = EXCLUSIVE;

    I plan on adding that to my alfred-clipboard.sh script in the future when I implement timstamp rewriting to make the history infinite:

    BTW if anyone is looking for a full script example that can clone, read, merge, etc otherwise poke into the Alfred clipboard db, you can find the source for my implementation here:

  2. I made a Workflow out of it, unfortunately the ergonomics are really bad because Alfred doesn't expose the clipboard-style preview pane UI to Workflows. With script filter output you can only display short snippets in the list.  Without the longer preview, it's really hard to tell which matches are correct and I found it next to useless.


    Thanks for that tip about the timestamps! I completely forgot about the Mac epoch having a different start date.


    I think the best long-term solution right now is to rewrite the Alfred sqlite db in place periodically to bump all the timestamps so that nothing ever expires.

    It's a hack, but lets me keep using the nice preview pane UI and the native Alfred search instead of a script filter workflow.

    The workflow can be found here: https://github.com/pirate/experiments/blob/master/Infinite Clipboard History.alfredworkflow (you'll need the script above to use it)


  3. +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)
    • important UUIDs
    • 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
            WHERE EXISTS(
                SELECT 1 FROM latest_db.clipboard latest
                WHERE $UNIQUE_FILTER
        /* 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'
    12590:3 Months


    (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).

  4. Please add this! The "open alfred" action in remote pops up alfred on my computer, great! now I can type in commands just like I could on my computer... but wait! not so fast, theres no keyboard!


    It would be so easy to add an option to send keystrokes, that way I can trigger my existing workflows and do anything on my system just like normal alfred.  I love having these buttons for convenient commands, so I only tap once to do things, but we should have them in ADDITION to normal alfred behavior, not instead of it.





  5. This is a limit imposed by UNIX, not Alfred, but the error message shown is slightly confusing, and there should be a way to overcome this issue.


    Right now, selecting more than exactly 260527 characters on my system and using it in an Alfred workflow (with the Argument:'selection in OS X' setting) as "{query}" will throw an error.

    You can see your system's bash argument character limit with:

    getconf ARG_MAX

    Alfred should allow a way to pass the selection as stdin instead of a quoted and escaped string, otherwise there is no way around this hard limit, and Line-Counting workflows, etc. are useless for larger bodies of text.


    ^ Confusing error message when selecting too much text.


    ^ A workflow example that would trigger this.



    echo "{query}" > .wordcount
    echo "Characters: "$(wc -m < .wordcount)"  Words: "$(wc -w < .wordcount)"  Lines: "$(wc -l < .wordcount)
    rm .wordcount

  6. Rather than using large type, if this code is in a file you could just use quick look to preview it from Alfred. There are plugins available for quick look that provide syntax highlighting I know

     I already have them and use them frequently, what I use Alfred's Large Type for is specifically highlighting one small segment of code and making it huge, as well as readable.

  7. As a coder I often use Alfred's wonderful large type key command to quickly display snippets of code to colleagues without all the other distractions on my screen.  If alfred provided built-in syntax it would make this much nicer.  If built-in is too heavy, I'd be happy to do the syntax highlighting myself, but alfred still needs to provide a method of colorizing Large Type output through a workflow.


    ASCII escape sequences are one option, but I'm sure our friends at HQ can think of a better solution.

  • Create New...