Community Contributions

[olimorris]

I'm very fortunate to get lots of messages every week from people asking how they can contribute to CodeCompanion. It's not necessarily an easy question to answer because I'm unsure of people's time commitments and what their desires are with the plugin.

So to make it easier for people, I thought I'd pin and keep updated a thread for enhancements that people in the community could contribute to if they so wish.

Important

This is not a place for feature requests. Please create a separate discussion for that. Let's use this to discuss collaboration and fleshing out ideas for enhancements.

How to Contribute

Just read the CONTRIBUTING.md guide. It's up to date and gives great advice on how to use CodeCompanion to contribute to CodeCompanion.

[olimorris]

✅ Improved Diff

Implemented in #1884.

---

Currently the @insert_edit_into_file and inline assistant use Neovim's in built :diffthis command as well as supporting mini.diff.

This is one area where support for additional plugins or a new and improved diff default would be valued by the community.

[bassamsdata]

Hello @olimorris,

I’m working on this feature (still in the early stages and not sure if it will see the light), but I had a few design questions I’d really appreciate your thoughts on:
• Would you prefer using unified diffs by default, or should we leave it as a user-configurable option? Personally, I lean toward unified diffs, similar to how Zed handles them (see image below).
• Do you have a preference between inline diffs or split view? I’m personally more inclined toward inline, though supporting both would take a bit more code.

What do you think? Overall, I’m aiming for something close to Zed’s diff style, but I’m open to other ideas if you have something different in mind.

the screenshot below is for a change diff

[olimorris]

Hey @bassamsdata! Hope you're all good and this would be a hugely welcome PR.

For me, Zed and VS Code's is the gold standard of diffs - unified and inline. It's much cleaner and I think more widely understood. I would welcome this PR so much and feel free to rip up everything that we currently have in place with regards to diffs.

The recent changes I made to insert_edit_into_file may take some of the complexity out the way as diffs are only shown if the user is asked for approvals. To that end, I wonder if there's some code we could "lift" from some of the popular Neovim diff plugins.

[bassamsdata]

Thank you, and I hope you’re doing well too.

For me, Zed and VS Code's is the gold standard of diffs - unified and inline

That sounds great!

feel free to rip up everything that we currently have in place with regards to diffs.

What a relief to hear that, as I was a bit concerned about major changes in diffs being introduced.

The recent changes I made to insert_edit_into_file may take some of the complexity out. To that end, I wonder if there's some code we could "lift" from some of the popular Neovim diff plugins.

I’ve been reading the latest version of the tool, and I agree it will definitely help. I haven’t looked closely at other plugin code yet, but I know mini.diff could be beneficial here, even though it uses a slightly different style.
I’ll also take a look at the git-conflict.nvim plugin and the newer unified.nvim. Although unified.nvim didn’t work perfectly for me, it follows a similar style.

I’ll most likely work on it this Sunday.

[olimorris]

✅ Additional Tool/Function Calling Support

Support for function calling is currently unavailable for some adapters such as mistral. A PR to add this would be valuable and I'd be willing to work with the contributor to support that.

[olimorris]

:CodeCompanionChat with more arguments

It would be great to be able to open a chat buffer with additional arguments that would allow for greater customization. For instance:

:CodeCompanionChat adapter=anthropic model=claude-sonnet-4 memory=claude Can you help me understand why #{buffer} is throwing lsp warnings?

potentially with completion...

[olimorris]

Coming in #2287

[olimorris]

✅ Improve @{insert_edit_into_file} tool

Currently the tool is unreliable for a number of different models. Whilst the logic for applying diffs and working between buffers and files is great, the patching algorithm is not where I want it to be.

EDIT: Closed in #2219.

[bassamsdata]

Delivering on my promise to work on this :) I developed a new mechanism for the edit file tool that follows many patterns used by major CLI agents and also relies on multiple flexible methods, so it can be improved easily and isn’t tied to a single algorithm.

The core structure is complete and working well, but it definitely needs additional fine tuning. I haven’t opened a PR yet because I want it to be very reliable first. If you’d like, I can open it as a draft PR.

[olimorris]

Feel free too and I'll be happy to test it out

[olimorris]

FYI, playing around with VS Code and I noticed they have anapply_patchtool:

{
    "function": {
        "name": "apply_patch",
        "description": "Edit text files. Do not use this tool to edit Jupyter notebooks. `apply_patch` allows you to execute a diff/patch against a text file, but the format of the diff specification is unique to this task, so pay careful attention to these instructions. To use the `apply_patch` command, you should pass a message of the following structure as \"input\":\n\n*** Begin Patch\n[YOUR_PATCH]\n*** End Patch\n\nWhere [YOUR_PATCH] is the actual content of your patch, specified in the following V4A diff format.\n\n*** [ACTION] File: [/absolute/path/to/file] -> ACTION can be one of Add, Update, or Delete.\nAn example of a message that you might pass as \"input\" to this function, in order to apply a patch, is shown below.\n\n*** Begin Patch\n*** Update File: /Users/someone/pygorithm/searching/binary_search.py\n@@class BaseClass\n@@    def search():\n-        pass\n+        raise NotImplementedError()\n\n@@class Subclass\n@@    def search():\n-        pass\n+        raise NotImplementedError()\n\n*** End Patch\nDo not use line numbers in this diff format.",
        "parameters": {
            "type": "object",
            "properties": {
                "input": {
                    "type": "string",
                    "description": "The edit patch to apply."
                },
                "explanation": {
                    "type": "string",
                    "description": "A short description of what the tool call is aiming to achieve."
                }
            },
            "required": [
                "input",
                "explanation"
            ]
        }
    },
    "type": "function"
}

alongside insert_edit_into_file:

{
    "function": {
        "name": "insert_edit_into_file",
        "description": "Insert new code into an existing file in the workspace. Use this tool once per file that needs to be modified, even if there are multiple changes for a file. Generate the \"explanation\" property first.\nThe system is very smart and can understand how to apply your edits to the files, you just need to provide minimal hints.\nAvoid repeating existing code, instead use comments to represent regions of unchanged code. Be as concise as possible. For example:\n// ...existing code...\n{ changed code }\n// ...existing code...\n{ changed code }\n// ...existing code...\n\nHere is an example of how you should use format an edit to an existing Person class:\nclass Person {\n\t// ...existing code...\n\tage: number;\n\t// ...existing code...\n\tgetAge() {\n\treturn this.age;\n\t}\n}",
        "parameters": {
            "type": "object",
            "properties": {
                "explanation": {
                    "type": "string",
                    "description": "A short explanation of the edit being made."
                },
                "filePath": {
                    "type": "string",
                    "description": "An absolute path to the file to edit."
                },
                "code": {
                    "type": "string",
                    "description": "The code change to apply to the file.\nThe system is very smart and can understand how to apply your edits to the files, you just need to provide minimal hints.\nAvoid repeating existing code, instead use comments to represent regions of unchanged code. Be as concise as possible. For example:\n// ...existing code...\n{ changed code }\n// ...existing code...\n{ changed code }\n// ...existing code...\n\nHere is an example of how you should use format an edit to an existing Person class:\nclass Person {\n\t// ...existing code...\n\tage: number;\n\t// ...existing code...\n\tgetAge() {\n\t\treturn this.age;\n\t}\n}"
                }
            },
            "required": [
                "explanation",
                "filePath",
                "code"
            ]
        }
    },
    "type": "function"
}

[bassamsdata]

Thanks for the info. Over the last two weeks I didn’t have access to my computer; the tool is on my local branch and working, but it’s not yet ready to integrate.

I know Code Companion follows GitHub Copilot in many areas, but I don’t think we should copy Copilot here since it doesn’t prioritize open source models. I think Code Companion values OSS models, and those models don’t always excel at patch-style workflows so to have both workflows will be redundant I think.

[olimorris]

✅ Support after/ftplugin for codecompanion

As noted in #2164, it would be amazing if after/ftplugin/codecompanion.{lua,vim} was supported by the plugin. Currently, anything put in an ftplugin file is overwritten by the chat buffer UI

[olimorris]

Fixed in #2251 👏🏼