bug: Avante ask open diffs to apply in a separated buffer?
Describe the bug
Hi everyone , love this code assistant but everything i want to apply a diff it opens the diff in a completely separated buffer eg:
Do you know why this is happening?
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
0.11.0
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
},
})
Could you share a screenshot of your sidebar?
Here it is
And when i apply with "A" i get all the diff in a separated buffer
Sometimes it works , but most times does what i described above.
and as you can see here , every time i tried to apply a diff i get this
I'm seeing this issue, also - it took me a while to realise that where my diffs were going until I quit and was reminded that I had 30 unsaved and untitled buffers :)
Can you check what your current project root is?
:lua vim.print(require("avante.utils").get_project_root())
And what is your cwd:
:lua vim.print(vim.uv.cwd())
From the file buffer or from any of the Avante windows (filetypes Avante, AvanteSelectedFiles, AvanteInput), running:
:lua vim.print(require("avante.utils").get_project_root())
gives me the correct project root (i.e. where .git is located for my project), and running:
:lua vim.print(vim.uv.cwd())
gives the directory of the file loaded into the buffer.
Note: I have the autochdir option set, which may be relevant...
Also (and this is another issue, but possibly related to use of autochdir) I was having some trouble with Avante not being able to locate files in the project again after restoring a session
I use sessions.nvim and lcd was being set in the session file, which caused Avante to get stuck in the directory of the last active buffer when the session was restored (in a directory often unrelated to the current project if I was jumping around across projects).
I solved this by adding an augroup that just runs vim.cmd.cd("%:h") on VimLeave which seems to have the effect of preventing the lcd from being saved in the session which is, I'm sure, a total hack :)
hey guys . Im 99% sure it is autochdir related thank you @joshbode ! this was affecting also copilotChat , i use autochdir for no real reason I don't think.
I don't know how to live without autochdir ;)
I had to set this:
if Config.behaviour.use_cwd_as_project_root then
because the lsp detector is running to find first, but where i'm poking around is in a monorepo. so the LSP is running in a subdirectory and reporting that it's running there, and get_project_root() is one level too deep vs. where my nvim is open.
I'm also having this issue in a monorepo, but I can't figure out how to fix it. Both
:lua vim.print(require("avante.utils").get_project_root())
and
:lua vim.print(vim.uv.cwd())
Give the root of the monorepo.
I ended up just doing this to temporarily disable autochdir inside Avante windows:
local chdir = vim.api.nvim_create_augroup("chdir", {})
vim.api.nvim_create_autocmd("BufEnter", {
group = chdir,
nested = true,
callback = function()
vim.go.autochdir = not vim.bo.filetype:match("^Avante")
end,
})
(note: setting nested seemed to be necessary to not break some other DirChanged auto-commands I have)
This approach seems to work, but there may be issues I haven't discovered yet!
I ended up just doing this to temporarily disable
autochdirinside Avante windows:local chdir = vim.api.nvim_create_augroup("chdir", {})
vim.api.nvim_create_autocmd("BufEnter", { group = chdir, nested = true, callback = function() vim.go.autochdir = not vim.bo.filetype:match("^Avante") end, }) (note: setting
nestedseemed to be necessary to not break some otherDirChangedauto-commands I have)This approach seems to work, but there may be issues I haven't discovered yet!
Thank you, this seems to have done the trick!
I had this issue, I installed LazyVim starter, no anything else, then install avante, it can ask to generate code snippet, but when I use 'a' to apply, it will open a "No Name" window to show the diff, I config to use self host ollama.
Same here. I am using a monorepo and I am using lazyvim. autochdir is disabled.
For me the issue seems to be somehow related to the use of NeoTree. I guess it somehow messes up the paths. As soon as I use NeoTree to open files Avante opens new buffers with the diffs.
Here is what the paths say:
-
Open file without neotree (works) 1.1 in open buffer
:lua vim.print(require("avante.utils").get_project_root())-> Root of the python package within my monorepo:lua vim.print(vim.uv.cwd())-> Root of my monorepo (.git) 1.2 in avante window:lua vim.print(require("avante.utils").get_project_root())-> Root of my monorepo (.git):lua vim.print(vim.uv.cwd())-> Root of my monorepo (.git) -
Open file with neotree (does not work) 2.1 in open buffer
:lua vim.print(require("avante.utils").get_project_root())-> -> Root of my monorepo (.git):lua vim.print(vim.uv.cwd())-> Root of my monorepo (.git) 2.2 in avante window:lua vim.print(require("avante.utils").get_project_root())-> Root of my monorepo (.git):lua vim.print(vim.uv.cwd())-> Root of my monorepo (.git)
So depending on the use of neotree the output of :lua vim.print(require("avante.utils").get_project_root()) changes for the current open buffer.
Hope that helps.
I tried the workaround mentioned by @joshbode but that unfortunately did not help for me.
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.
This issue was closed because it has been stalled for 5 days with no activity.