We have a large code file (360k lines).
At the moment it is not feasible to split it into smaller chunks.
When I prepare a change in the chat window and hit apply, nothing happens, except that the code change is marked as “canceled” (small red x near filename).
I guess it has to do with the file size.
Is there any workaround for this, other than splitting the original file?
Same issue. What I do is have it use sed or awk commands and sometimes python. Would be nice if the edit_tool would work on large files
The agent’s capabilities to edit big files shouldn’t get any worse with big files, that’s what it was trained to do!
Next time you see this, can you try sending us over a request ID to look into, using the following guide:
My friend but what happens most is that the agent can’t edit a big code like that
I made a project of 70 thousand lines I had to do almost everything by hand the changes because he always got it wrong or put duplicate Def
Alright, here is the request ID:
ff1d5484-62ae-4424-bf49-d2f9cd1c0029
a75f6d80-3377-4c0b-9409-49a7e426be1f
I can reproduce this each time.
Now that the agent is active in composer, it tries to insert code, fails, apologises then tries again in a loop.
Before the Agent was active, I would get the problem as stated obove in my original post.
Steps to reproduce:
Take a large file containing code.
Using Composer, try to make changes around line 100.000 (around line 137.000 in my case).
If I do same at lower lines (around 5000) - it works.
If I extract the piece of code in a new file and edit it there, it works.
Here are a few more requests that failed:
d2582302-3236-4e1c-b101-90adebf714c5
c0f348eb-4d8c-49a3-b4ab-2145c546a850
Note: I have observed a simmilar problem in the VS Code with copilot. So maybe look there, instead of your own code.
You are wellcome to contact me if you have any more questions. I believe you have my email address.
Additional info, maybe the same problem.
If I go to line 137806 (or any higher that 50.000 I think) and press Ctrl+K to start edit, no edit prompt window appers, the carret jumps to line 269682 (around double the way down), and in the original place, there is an empty space, where the Prompt window should have been.
Here is what it looks like when it works (low line numbers)
This is something that happens to me frequently, since several versions ago, it’s not something recent, and not with really big files, even with 1500/2000 lines files, and I think especially with Claude Sonnet.
A solution that I often use is to tell composer to show me the diffs directly, then I apply the changes directly there, for this to work, if there are changes in different files, you have to go through each file and when it’s visible/opened, apply the diff, otherwise composer will try to do it in the currently visible file only and it won’t work.
not sure if this would help but have you tried using the new gemini pro model? It has a larger context size so maybe it’d perform better with a file this big
Hi @Hrnkas , did u manage to find a good solution for this issue?
Facing the exact same problem, working around it by generating a script that extracts the necessary parts, makes updates and merges it back to the initial file, but it’s a huge mess…
Lmk if u solved it
I have tried - same problem
Not yet, I am hoping the guys from Cursor are going to fix it soon. They are usually very fast with fixes and new features.
Thanks for the detailed report and request IDs! You’re right that there’s an upper limit on file sizes for the apply functionality - for now the best workaround is probably to use the diff view approach that @dannetstudio mentioned, or extract the section you want to edit into a temp file
I’ll pass this to the team to see what’s possible regarding increasing the limit of our apply model, to support these larger uses!
As alternative, if you could enable Apply to patch the files using the typical git patch algorithm, it would allow to edit files of any size. I am just not sure how would you then show the changes.
We do want to increase the file size limit for apply, so I would expect to see some improvements on this in the near future!
Unless you change it to 300k lines or 4.5 million tokens, it won’t help my use case.
Will keep this in mind, you may be right in needing some kind of ‘patch’ logic here!
I appreciate that.
Is there a way I can contribute to the project?
I love the tool, but I see a couple of things that could be improved. I have 25 years of experience in the industry, and 24,9 years of debugging.
If I could test the solutions before the official release, I would be glad to do it.
I can invest 1-2 hours a week for that.
Really appreciate the offer! We don’t have a formal testing program yet, but we’re hoping to add a ‘canary’ build soon that would let users test new features before they go live. In the meantime, the best way to help is through detailed bug reports like you’ve been doing - those request IDs and repro steps are super helpful for the team
I can understand that.
Basically, +1
I’ve run into issues when tried Cursor to manipulate helm-charts/charts/kube-prometheus-stack/values.yaml at main · prometheus-community/helm-charts · GitHub
~5300 lines of code.
Used Agentic mode claude 3.7 thinking
File isn’t rich in content, it’s more or less comments, and Cursor actually stripped it to ~3000 lines which came later problematic. It was easy to fix, but still, I am not really able to manipulate parts of the file.
That would be great if manipulation of larget files would work better - I may assume as Cursor acts as a middleware, API tokens provided there are actually higher tier once, therefore, it doesn’t look to me like if it would be an issue to raise up a limit/make it configurable for PRO users.
