Debugging banana is not the simplest thing to do
The lua code is easy to debug if you already no how to debug lua with osv. I personally use do-the-needful to start up debug tmux windows really easily. The script i use to launch lua debug is the debug one in .tasks.json.
Debugging the zig code is not as easy
This requires attaching to a running neovim process that ALREADY has the zig .so included with lua ffi. It also requires special privilege overriding in linux
to first override privileges so that gdb can attach to a process without any problems requires this to be run in a shell:
echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope
Then, you need to have gdb installed on your system and have this configuration for zig:
dap.configurations.zig = {
{
name = "Select and attach to process",
type = "gdb",
request = "attach",
pid = function()
local name = vim.fn.input('Executable name (filter): ')
return require("dap.utils").pick_process({ filter = name })
end,
},
-- this is so that we keep any other configurations
unpack(dap.configurations.zig),
}
dap.adapters.gdb = {
type = "executable",
command = "gdb",
args = { "--interpreter=dap", "--eval-command", "set print pretty on" }
}
After that is setup, you need to launch a neovim process, ensure that the zig .so is loaded, and then you can connect by just launching the above configuration and selecting the neovim process
The zig debug script in .tasks.json contains a command to launch neovim with an init.lua that ensures that the zig shared object is loaded, it is recommended to use that script to test any zig problems
There are also a few intricacies to finding the right neovim process. On my machine (using the bob version manager for neovim), there are three processes started up when i open neovim. The important one is the one that is launched with the --embed flag. That is the one to connect to to debug the zig code