New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ability to store unlimited clipboard data #310
Comments
FYI, this is not an issue but a feature enhancement, it should be tagged as such. |
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? |
Closing since no reply for more than a month. Feel free to re-open and provide more info. |
I would like to have a much more larger history than 999 but not unlimited. |
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.
|
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? |
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.
No, there is no such thing, you can only ignore by app or pasteboard type. |
I agree with this feature. |
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. |
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. |
+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. |
I use 10k as limit on Ditto. And the search is always instant. |
Good for Ditto, I wish NSMenu was as fast. |
I've been using Raycast app to access clipboard history. Just enable Clipboard History extension and you are good to go.
Thanks @banuragaxioned for recommending this app. |
Good for Raycast, I wish NSMenu was as fast. |
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. |
The problem is not with fuzzy searching, threading, or libraries, the problem is that the core AppKit component called Also, PRs are always welcome. |
Now I see. However, I don't know why implementing this depends on |
This would be ideal, though making such a dynamic menu is not a trivial task. |
+1 Would love to have this! |
@p0deje, how approachable do you think this issue is? I am familiar with swift, and could take a stab at it. |
@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. |
That's probably beyond my scope unfortunately |
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. |
+1 Would love to have this! |
+1 |
+1 for more items to store. |
+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 |
+1 Having more text saved than 999 would be life saver for me |
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>; |
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.
The text was updated successfully, but these errors were encountered: