remove 2048 byte clipboard limit for macos #2087
Conversation
|
Thanks! this is very much needed! 💯 |
|
I marked this as Draft, pending macOS etc. testing. Should this branch become |
|
I can confirm this fix works on macOS 14.6.1, also tested with larger chunks of text and edge cases like this. My attempts to use less memory, explicitly use autoreleasepool and to run on the main thread didn't improve stability or memory usage. Virtual memory fills up with this solution, just as it does with mine. Real and private memory are released with this solution, just as with mine. |
|
Good! I see this good in general sense. I have only one question, is this PR opening a bug about memory or the bug already exists? This is what is not clear to me (sorry for being so out of the loop!)
|
|
The bug, or more likely bugs, already exist: #1675. I’d say it is not solely related to the keystrokes, as mentioned by Federico in the issue. When you copy and paste large clipboards (which you can now do, thanks to this PR), you can see the virtual memory growing with each repetition, and it doesn't get freed correctly. |
|
I can confirm this also works in macOS 15.0.1. |
|
Superseded by #2089 . Just a coincidence that were two very similar approaches 🤞🏼 . |
This PR aims to resolve #1612 and #2051 on macOS by replacing the previously hardcoded 2048-character clipboard size with an adaptive size based on the actual clipboard content length.
Note: This pull request is untested on macOS.
Unfortunately, I do not have access to a macOS environment at the moment, but I believe this solution should address the issue. Testing is necessary before merging.
This change is similar to the fix in #2085, with the key difference being in the native code for
clipboard_get_length. The logic mirrors that ofclipboard_get_text, except it usesstrleninstead ofstrncpyto determine the required length.Please ensure that the code is tested on macOS before proceeding with the merge.