Open samwdp opened 6 days ago
After a bit more digging, I have found that changing the buffer name to a name without any asterisks in it stops this error. Not sure why this is so having the following config surpresses this error
return {
"ej-shafran/compile-mode.nvim",
-- you can just use the latest version:
branch = "nightly",
-- or the most up-to-date updates:
-- branch = "nightly",
dependencies = {
"nvim-lua/plenary.nvim",
-- if you want to enable coloring of ANSI escape codes in
-- compilation output, add:
{ "m00qek/baleia.nvim", tag = "v1.3.0" },
},
config = function()
---@type CompileModeOpts
vim.g.compile_mode = {
buffer_name="compilation",
-- to add ANSI escape code support, add:
baleia_setup = true,
}
end
}
Interesting. We've had issues with the asterisks in the buffer name in the past on Windows, but I believed I had fixed them (also, the Windows tests don't seem to show this issue). I'll try to give this a look.
Can't seem to reproduce this error in the tests. Mind creating a reproduction in a container or something of the sort? Seems like the issue is pretty dang specific...
Existing Issues
Describe the bug
When running compile for the first time the error
Error executing Lua callback: .../nvim-data/lazy/plenary.nvim/lua/plenary/async/async.lua:18: The coroutine failed with this message: .../nvim-data/lazy/plenary.nvim/lua/plenary/async/async.lua:18: The coroutine failed with this message: vim/_editor.lua:431: nvim_exec2(): Vim(sbuffer):E303: Unable to open swap file for "*compilation*", recovery impossible
Then when the *compilation* buffer is open and a Compile or Recompile command is run the output is correct
I have already set my nvim directory by doing vim.opt.directory = "my_location" in my init.lua. I can see swap files created in there for the buffers I have open. I have no other issues with plugins that use Plenary
Steps To Reproduce
Expected Behavior
Complation buffer opens and output is shown
Neovim Version
Plugin Version
Configuration
Additional Context