bug: Apply doesn t work as expected

[m1cl]

Describe the bug

Currently I am not able to apply suggested changes. Using capital A will jump back to my buffer. When I use 'a' inside avante I get a message that the buffer is not modifiable. I got this behavior since day one. Changing models helped sometimes but usually I ended up selecting the code manually and paste it to the buffer.

gonna stick with zed editor until it is more mature.

To reproduce

No response

Expected behavior

No response

Installation method

Use lazy.nvim:

{
  "yetone/avante.nvim",
  event = "VeryLazy",
  lazy = false,
  version = false, -- set this if you want to always pull the latest change
  opts = {
    -- add any opts here
  },
  -- if you want to build from source then do `make BUILD_FROM_SOURCE=true`
  build = "make",
  -- build = "powershell -ExecutionPolicy Bypass -File Build.ps1 -BuildFromSource false" -- for windows
  dependencies = {
    "nvim-treesitter/nvim-treesitter",
    "stevearc/dressing.nvim",
    "nvim-lua/plenary.nvim",
    "MunifTanjim/nui.nvim",
  },
}

Environment

NVIM v0.10.4 macos

Repro

vim.env.LAZY_STDPATH = ".repro"
load(vim.fn.system("curl -s https://raw.githubusercontent.com/folke/lazy.nvim/main/bootstrap.lua"))()

require("lazy.minit").repro({
  spec = {
    -- add any other plugins here
  },
})

[yetone]

‌‌‌‌Could you provide the model you're using and a screenshot of the sidebar?

[jonathancyu]

I'm also able to reproduce this on the latest commit. Entering "a" or "A" will return me to the main buffer without adding any diff hunks.

I have tried clearing the chat, as well as restarting, to no avail. Top of the sidebar:

A lot code in between... Bottom of the chat:

[yetone]

Do you see this prompt in the upper right corner of the code block when your cursor is in this area?

[jonathancyu]

Hey - thanks for the quick response! Yes I do. I tried to reproduce (semi-successfully) in two different projects: In this one, you can see the bug in this issue occur arround 12 seconds, but it works outside of that. It seems the prompt response buffer got duplicated incorrectly? Not sure what happened there... https://youtube.com/shorts/4BTJ4_wMaRo

For this one (different repo), I wasn't able to get apply to working whatsoever. Every time my cursor goes back to the main buffer I'm hitting a (or A). https://youtube.com/shorts/GH0DuRjh9Qw

As a further debug step, I tried deleting the .local/state/nvim files associated with the second project but this had no effect.

[yetone]

‌‌‌‌The first video is so strange, why are there two avantes in the sidebar? 🤔

[yetone]

‌‌‌‌‌Is your current avante the latest version?

[jonathancyu]

That was the latest as of last night (commit 78d6c38). I updated to the latest commit d698dbe which seemed to have fixed it, but when I reverted to 2cd6d93 (which reproduced the bug), and then reverted again to d698dbe the issue was back...

I believe I have pinned down what the issue is - when applying, avante will apply the diffs to an untitled buffer in the CWD: For example, applying this change opens a buffer with this content:

<<<<<<< HEAD
=======
    // Close popup only when clicking the overlay background
    // e.target is the clicked element, while e.currentTarget is the element with the attached listener
    // This prevents closing when clicking on any child elements within the popup
>>>>>>> Snippet

[maartenq]

Having same issue: not able to apply suggested changes. Using capital A will jump back to my buffer. When I use 'a' inside avante I get a message that the buffer is not modifiable.

I don't see the prompt in the upper right corner of the code block when my cursor is in this area.

OS: Arch Linux 6.13.8-arch1-1 ➜ nvim --version NVIM v0.11.0 Build type: RelWithDebInfo LuaJIT 2.1.1741730670 ● avante branch main commit c272bcd

============================================================================== avante: require("avante.health").check()

avante.nvim ~

• OK Found required plugin: nvim-lua/plenary.nvim
• OK Found required plugin: nvim-treesitter/nvim-treesitter
• OK Found required plugin: MunifTanjim/nui.nvim
• OK Found required plugin: stevearc/dressing.nvim
• OK Found icons plugin (nvim-web-devicons or mini.icons)

TreeSitter Dependencies ~

• OK TreeSitter core functionality is available
• OK All essential TreeSitter parsers are installed
• OK TreeSitter highlighter is available

==============================================================================

[Aoriseth]

I'm having the same issue with the latest version installed via lazy yesterday. Unable to see a prompt to apply, and just getting the buffer is not modifiable when trying to use A, or a.

I'm using chatgpt 4o for planning.

[mikemc]

I started having this issue as well; as reported by jonathancyu, the diffs were ending up in an untitled buffer. But as of yesterday (commit 89a86f0) things seem to be working for me again. (I may have also updated to Neovim v0.11.0 in between things not working and working again)

[jonathancyu]

The problem has re-appeared again for me. I'm curious if the same is for @mikemc, it seems updating (perhaps re-building avante) temporarily fixes the issue.

I have noticed that the issue appears more likely in monorepos. For example, in this repository, opening nvim in the root will cause the untitled buffer bug. However, if I cd frontend and run nvim my changes will be properly applied again.

[xarthurx]

I started having this issue as well; as reported by jonathancyu, the diffs were ending up in an untitled buffer. But as of yesterday (commit 89a86f0) things seem to be working for me again. (I may have also updated to Neovim v0.11.0 in between things not working and working again)

I have the same issue. When applying the changes, nvim will open a new untitled buffer and put all changes there, instead of to the original buffer.

I'm using copilot-version of claude.

[rzyanhao]

+1 same promble, when applying, it will open a new untitled buffer

[AlpMimaroglu]

Same for me. Strangely it happens with openai-4.1mini but it works fine with 4o.mini

[xarthurx]

With recent update, this issue seems run away, though I only tested github models.

[AlpMimaroglu]

With openai the issue is still present for me

[eli-front]

Seeing this with claude 3.5. When I apply it applies the changes to an empty buffer instead of the current file

[DaitiDay]

I am getting the same problem. It's weird because this morning everything was working fine, but now when I hover a codeblock I do not get the tooltip ": apply this, <A>: apply all", and pressing either A or a does nothing (pressing a actually gives an error message saying the buffer is not modifiable as already reported above). I reverted all other changes I did between the last successful run and the first insurgence of the problem (added blink-cmp-avante and activated cursor planning), but with no success. I'm using ollama at the moment. Don't know if it is a useful information, but editing a selected block (ae) works as expected.

[xarthurx]

I'm using Visual Studio and its Copilot recently.

I also sometimes has this issue of not applying to the original code. From what I observed, it seems that the mechanism for such action is:

1. The generated code has some "connecting pieces" -- a small code block from the original code.
2. When applying to the original code, the agent search for this "connection piece", and replace onwards.
3. When they cannot find the "connecting pieces", fallback mechanism will happen:

• For Visual Studio, it inserts the new code under the cursor.
• For avante, I guess it apply to a new buffer.

This resolves the question replied in this issue that some times it works and some times it doesn't (even for the same user, same engine) -- It differs by code pieces, not by machine or software version.

[ronualdo]

Similar thing here. I was not able to fully debug it but my guess is that sometimes the model that I was using was not returning the "SEARCH/REPLACE" blocks.

The reason that I say that it's because sometimes it returned an answer with the ruby blocks but I was not able to apply them. So, I send a prompt saying "Can you implement that?" and then it returned a new answer where the apply was working. I was using a local ollama instance using the qwen2.5-coder:7b model

[DaitiDay]

I tried that with no success

[DaitiDay]

Are there updates regarding this issue?

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[ckoehler]

Seeing the same thing with Claude 3.7 from Copilot with o3-mini as the applying model. Changes go into a new buffer.

[yetone]

Seeing the same thing with Claude 3.7 from Copilot with o3-mini as the applying model. Changes go into a new buffer.

Are you using the latest version? The concept of applying model was removed from Avante a long time ago.

[ckoehler]

Are you using the latest version? The concept of applying model was removed from Avante a long time ago.

Good call, I'm pretty far behind on f9aa754 from April. Ignore my comment.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[github-actions[bot]]

This issue was closed because it has been stalled for 5 days with no activity.