Merge @editor into @files

[ravitemer]

What do you guys think about having a single @files tool with @editor tool functionality added:

• Opens the buffer in the editor when creating a file
• Shows diff view when editing a file like how @editor does

[olimorris]

I think it makes a lot of sense and would streamline the UX quite a lot. As a user, I don't care about whether an LLM is editing a file or a buffer. I just want it to apply the changes for me.

This will see us move away from the current approach in the editor of tracking changes via line numbers. I'm totally fine with that.

[ravitemer]

If in case we just have the @files tool, it doesn't need line numbers to update the file.

[olimorris]

I don't follow from discussion why line numbers can be removed?

Line numbers were a way of making sure we could apply multiple edits to a single file in a token efficiency way. It was an alternative to a common design pattern which uses search and replace blocks.

[olimorris]

remove the /buffer given users are accustomed to these names and make more sense in a neovim environment.

/buffer has to stay. It's a slash command for loading context into the chat buffer. It has nothing directly to do with tools.

[daliusd]

I am asking because I don't know how @files work internally. Are files using search and replace? This article covered quite some options that are available https://cookbook.openai.com/examples/gpt4-1_prompting_guide

[pratyushmittal]

@daliusd The @files tool implements the exact same technique (using diffs) that OpenAI recommends in the guide.

Aider too recommends this approach and found 3x improvement over other techniques: https://aider.chat/2023/12/21/unified-diffs.html

[pratyushmittal]

💯

@files provides all the functionality that @editor provides and hence can replace it. It will allow user to reference files even if they are not already open in the buffer.

The only use of @editor can be in instances where we want to refer to a buffer which is not part of the project. I don't think this happens too often.

[jinzhongjia]

I think this merge is perfectly OK. The scenario where I use @editor is that I don't want llm to directly modify the file, but modify the buffer. If something goes wrong, I will cancel it directly

[meijieru]

Similarly, a key difference is that the files tool doesn't enter diff mode. It would be highly beneficial if editing could open in a diffing tool like diffview.nvim, allowing partial or full acceptance of changes.

[deas]

I think I am hitting an issue with the files tool.

Using the following prompt with Copilot / gpt-4o and a single file context:

Use @files to make the following changes:
...

Getting:

[WARN] 2025-05-10 06:47:23
Tool files: ...lua/codecompanion/strategies/chat/agents/tools/files.lua:248: Diff block not found:

@@(case operation
        "read" (read-registration config options)
        "write" (write-registration config options)
        (exit-error 1 (str "Unknown operation: " operation "\n\n" (usage summary)))))
-        (exit-error 1 (str "Unknown operation: " operation "\n\n" (usage summary)))))
+        "app" (launch-app config options)
+        (exit-error 1 (str "Unknown operation: " operation "\n\n" (usage summary))))))

@@;; --- Operations --- (read-registration and write-registration remain the same)
+;; --- Launch App ---
+(defn launch-app [config options]
+  (require '[org.httpkit.server :as http]
+           '[hiccup.core :refer [html]])
+  (let [form-page (fn [registration-json]
+                    (html [:html
+                           [:head [:title "Registration Form"]]
+                           [:body
+                            [:form {:method "post" :action "/submit"}
+                             [:textarea {:name "registration" :rows 20 :cols 80} registration-json]
+                             [:br]
+                             [:input {:type "submit" :value "Submit"}]]]])
+        registration-json (try
+                            (json/generate-string (api-request config :get "/realms/master/clients-registrations/default") true)
+                            (catch Exception _ "{}"))]
+    (http/run-server
+     (fn [req]
+       (case (:uri req)
+         "/" {:status 200 :headers {"Content-Type" "text/html"} :body (form-page registration-json)}
+         "/submit" (let [body (slurp (:body req))]
+                      (try
+                        (api-request config :post "/realms/master/clients-registrations/default" :body (json/parse-string body true))
+                        {:status 200 :body "Registration submitted successfully."}
+                        (catch Exception e
+                          {:status 500 :body (str "Error: " (.getMessage e))})))
+         {:status 404 :body "Not Found"}))
+     {:port 8080})
+    (println "Server started on http://localhost:8080")))

Not sure how deep the waters are, but it goes via 245 before it fails in 248.

Should I raise this as a bug along with a full repro?

[pratyushmittal]

Thanks @deas for sharing the file. The diff merge failed here because of the bad diff provided by the LLM response:

        (exit-error 1 (str "Unknown operation: " operation "\n\n" (usage summary)))))
-        (exit-error 1 (str "Unknown operation: " operation "\n\n" (usage summary)))))

It copied the same line twice. Once to not change it, and then again to mark it for deletion.

This happens sometimes. Most models are able to identify it and self-heal when you return the error back to them (just hit enter).
This has also improved a lot in newer models such as gpt-4.1 and o3 which have been specially trained for these use cases.

-- Edit (around resubmission) --
While resubmitting, you can also nudge the LLM in right direction if it fails to find its error.

[deas]

Thanks @pratyushmittal !

Somehow had the suspicion the root cause of this would be in deeper waters. :)

[deas]

Some quick observations/thoughts/questions:

• gpt-4.1 fails for me in a similar way.
• How could one try to nudge the model around this? Maybe doing this with the initial prompt, so the issue does not even surface?
• I may be missing something, but maybe we can allow the user to fix the diff manually?
• In the modal dialog asking "Edit ...?", I sometimes get no entries to choose from.
• Clojure is a niche language. Does that make a big difference with regards to diffing capabilities?

[deas]

No idea why, but I cannot reproduce the patch failure with gpt-4.1 - it works for me now.

[pratyushmittal]

Some quick observations/thoughts/questions:

• gpt-4.1 fails for me in a similar way.
• How could one try to nudge the model around this? Maybe doing this with the initial prompt, so the issue does not even surface?
• I may be missing something, but maybe we can allow the user to fix the diff manually?
• In the modal dialog asking "Edit ...?", I sometimes get no entries to choose from.
• Clojure is a niche language. Does that make a big difference with regards to diffing capabilities?

I have an algorithm in mind which can handle even the bad diffs. Let me give it a try.

[olimorris]

I've given this some thought over the past week. I think that we definitely need to fold most of the @files logic in to @editor (and along with that make some significant changes elsewhere in the plugin). However, my preference is to keep the two tools distinct from one another, for now.

My primary reasoning is I would want to retain full approval rights over any edits that an LLM makes to files on my file system. But I'm more than happy for it to have free reign to make changes in any buffers that I have open in Neovim. In a worst case scenario, an LLM makes some erroneous edits to some files in my file system and I can't undo them. With the editor tool, in a worst case scenario, the LLM makes some erroneous edits to some buffers and I can just undo them within Neovim.

We also need to massively improve the diff feature in CodeCompanion. And it's likely that we'll need to put a lot of logic relating to that in the tool itself. I don't want to muddy the @files tool anymore and I think keeping them distinct is just cleaner.

EDIT: And what I should have said, is I expect a lot of the awesome work that's been done in @files could sit in a general helper file that @editor can leverage as well. Be good to get everyone's thoughts on this.

[pratyushmittal]

Hey @olimorris, totally agree with your thoughts.

I can work on refactoring @files and move patch handling part into a separate utility file.

I also have another algorithm in mind to improve the patch merges. Basically a way to merge diffs confidently even if the LLM made some errors in diff generation.

Improved algorithm for patch merges (with errors):

• Currently we try to find the line where the patch matches with the focus, pre and post lines.
• Instead of trying to find a perfect match, we can compute a match_probability for every line.
• Then pick the line with highest match probability.
• match_probability = number of matching pre and post lines / total number of lines in diff
• This can handle cases like these. These happen ~10% of the times.

I can try to work on above two changes over this weekend.

[olimorris]

@pratyushmittal that would be amazing! Very, very excited for this.