Ability to store unlimited clipboard data

[naqushab]

Thanks for this app. A great alternative to Ditto Clipboard manager on Windows. Ditto has an additional ability to store unlimited clips ( I know it is sounds too much), but maybe you can add that too), or instead of slider we can actually input a number?

Again, thanks for this wonderful app.

[naqushab]

FYI, this is not an issue but a feature enhancement, it should be tagged as such.

[p0deje]

I understand that it would be cool, but what's the actual benefit of having unlimited history? I am fairly certain it will cause issues (slow search, NSMenu issues) and I don't see any value for me to have it. Can you elaborate?

[p0deje]

Closing since no reply for more than a month. Feel free to re-open and provide more info.

[krishna2vinayak]

I would like to have a much more larger history than 999 but not unlimited.

[p0deje]

Do you have any particular number you would like to store?

Thank you, Alex On Nov 1, 2021, 09:27 -0700, krishna2vinayak @.***>, wrote:

I would like to have a much more larger history than 999 but not unlimited. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub, or unsubscribe.

[krishna2vinayak]

How about 15k or 20k? I'm not sure if it slows down the search. I usually only use text copies as my work involves too many copy pasting and it's helpful to search it from one place than switching webpages. Also, does the app have any feature to ignore specific text just like histignore in bash?

[p0deje]

How about 15k or 20k? I'm not sure if it slows down the search. I usually only use text copies as my work involves too many copy pasting and it's helpful to search it from one place than switching webpages.

Fuzzy search is getting slow on 200+ records, but the real problem is that we have to hide anything above 999+ from the menu, otherwise the menu itself will be slow and slow loading. I'll need to investigate this in more details.

Also, does the app have any feature to ignore specific text just like histignore in bash?

No, there is no such thing, you can only ignore by app or pasteboard type.

[Axenntio]

I agree with this feature. Why not adding an Unlimited checkbox next to the slider (which can gray-out the slider?). Auto-disabling fuzzy search in this context can be a life saver for people.

[Petri-Oosthuizen]

What if you placed a limit on the menu size? Say limit the menu to 300 - I'm pretty sure few people scroll that far down - and then only enable finding items by search. At the end of the 300 items a "show more" option can be shown.

[p0deje]

I need to figure out #384 first because right now all the history is stored in memory. Once I tackle this, I'll try to implement unlimited history.

[epifeny]

+1 I would also like to see this unlimited history given as an option to the user. As a DevOps engineer, I work with my clipboard quite a few hours of the day and 999 history rotate every few days. I use a lot of commands that I reuse on a daily basis, throughout the year and I need those to be always available to me when I need them.

[vipiny35]

I use 10k as limit on Ditto. And the search is always instant.

[p0deje]

Good for Ditto, I wish NSMenu was as fast.

[vipiny35]

I've been using Raycast app to access clipboard history. Just enable Clipboard History extension and you are good to go.

• Works like just like ditto minus few advanced configurations.
• Setup a Hotkey to quickly open the clipboard history. Search. Press Return to paste. 🚀🤩
• UI is 10x better than Ditto, but that didn't matter much to me.
• Clipboard seems to be unlimited but clipboard retention max period is 3months, which worked fine for me.
• Clips when reused brings up the top which can be reused again for 3 months.

Thanks @banuragaxioned for recommending this app.

[p0deje]

Good for Raycast, I wish NSMenu was as fast.

[Slackadays]

How slow would an unlimited/extended history actually be? The new M1/M2 Macs are so fast that it might not be a problem. Alternatively, you could make a special helper library that does nothing but searches clipboard history and is optimized. Or, you could disable fuzzy searching like someone suggested. If grep can search gigabytes of content per second while using plain-old C and single threading, there's no reason Maccy can't.

[p0deje]

The problem is not with fuzzy searching, threading, or libraries, the problem is that the core AppKit component called NSMenu is not optimized for such huge lists and it takes time to (re)render it. Additionally, everything is stored in memory so it would easily result in Maccy using gigs of RAM.

Also, PRs are always welcome.

[Slackadays]

Now I see. However, I don't know why implementing this depends on NSMenu rendering everything, as you could render only what could possibly be visible, and this would also make regular usage faster as well. This is basically what video games do by calculating what's occluded and throwing all of that out.

[p0deje]

This would be ideal, though making such a dynamic menu is not a trivial task.

[jaspermayone]

+1 Would love to have this!

[jaspermayone]

@p0deje, how approachable do you think this issue is? I am familiar with swift, and could take a stab at it.

[p0deje]

@j-dogcoder The whole storage solution probably needs to be reworked to properly use Core Data with https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/CoreData/Performance.html in mind. I think I did some poor decisions when I implemented it as I didn't really understand how it works back then. Once this is done, the dynamic menu could be worked on.

[jaspermayone]

That's probably beyond my scope unfortunately

[digitalmaster]

Downloaded this because Alfred is also refusing to let us control the limit. 😢

I really wish I could just say for example "Use max 1GB". instead of an arbitrary limit.

[i6941]

+1 Would love to have this!

[0xAl3xH]

+1

[sergeyka]

+1 for more items to store.

[krushnadeore]

+1 the limit of 999 should increase , i also made one more request long time ago for extracting all in pdf or CSV format in app itself but @p0deje suggestion of sqlite db loaction also worked thanks

[br1nq]

+1 Having more text saved than 999 would be life saver for me

[mihaitodor]

Thought I'd point out that CopyClip uses SQLite under the hood to address this issue. I found myself once or twice having to search through older clipboard history (see below), but 999 items seems like a reasonable limit. I might disable images if Maccy ends up using too much memory.

> cd /Users/mihaitodor/Library/Containers/com.fiplab.clipboard/Data/Library/Application\ Support/CopyClip
> sqlite3 copyclip.sqlite
sqlite> # You can use a `LIKE` clause on `ZCONTENTS` if you know what you're looking for
sqlite> select * from ZCLIPPING order by ZDATERECORDED desc;
sqlite> select ZCONTENTS from ZCLIPPING where Z_PK = <some ID>;

[aaarel]

+1 for storing unlimited text only. menu can be as short or even non existent since there is a search box

[dagadbm]

i believe 999 is indeed very short.

I have scripts I run once every month or so and every time I need them they have been erased from this app. It is extremely annoying

[jaspermayone]

@p0deje given the rewrite with V2, is this a feature that's now possible?

[p0deje]

@jaspermayone In my limited testing, the performance degrades with a couple of thousand entries. It should be possible now with 2.0 rewrite, but I'm yet to see how exactly. I would consider this to be a feature for 3.0 at the very least.

[jaspermayone]

That would be amazing!