p0deje / Maccy

Lightweight clipboard manager for macOS
https://maccy.app
MIT License
11.51k stars 495 forks source link

Ability to store unlimited clipboard data #310

Open naqushab opened 2 years ago

naqushab commented 2 years ago

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 commented 2 years ago

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

p0deje commented 2 years ago

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 commented 2 years ago

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

krishna2vinayak commented 2 years ago

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

p0deje commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

+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 commented 1 year ago

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

p0deje commented 1 year ago

Good for Ditto, I wish NSMenu was as fast.

vipiny35 commented 1 year ago

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.

image
p0deje commented 1 year ago

Good for Raycast, I wish NSMenu was as fast.

Slackadays commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

jaspermayone commented 1 year ago

+1 Would love to have this!

jaspermayone commented 1 year ago

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

p0deje commented 1 year ago

@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 commented 1 year ago

That's probably beyond my scope unfortunately

digitalmaster commented 1 year ago

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 commented 1 year ago

+1 Would love to have this!

0xAl3xH commented 10 months ago

+1

sergeyka commented 8 months ago

+1 for more items to store.

krushnadeore commented 8 months ago

+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 commented 6 months ago

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

mihaitodor commented 4 months ago

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 commented 3 weeks ago

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