rcarriga / nvim-dap-ui Goto Github PK

When I start a debugging session, the sidebar opens as expected. In my case I have set the tray to not open on start, so it does not appear with the sidebar:

dapui.setup({
  ...
  sidebar = {
    open_on_start = true,
    ...
  },
  tray = {
    open_on_start = false,
    ...
  },
  ...
})

When I call require("dapui").toggle() to hide the sidebar, the sidebar goes but the tray opens up.

This is technically correct, since the tray visibility has been toggled. But ideally, I would like to disable the tray becoming visible on toggle, since open_on_start is false.

Is this something that can be addressed in the plugin, or should users come up with a workaround for cases like these in personal configs?

I see here that regardless of the original color scheme, the UI scheme is constant. Wondering if there is a good way to match the theme.

When I run dapui close the virtual text stay visible. I have to restart nvim to get rid of it:

i get the following error:

Error executing vim.schedule lua callback: ...ack/packer/opt/nvim-dap-ui/lua/dapui/elements/stacks.lua:32: attempt to concatenate field 'line' (a nil value)
Error executing vim.schedule lua callback: ...ack/packer/opt/nvim-dap-ui/lua/dapui/elements/stacks.lua:32: attempt to concatenate field 'line' (a nil value)

it will just throw the error debugging works like intended
this happens every time i hit a breakpoint
also scope window is empty stacks says no expressions

i guess this might be my configuration somewhat link to nvim dotfiles

this is the config that gets loaded when i lazyload dap

local dap = require "dap"

dap.adapters.node2 = {
    type = "executable",
    command = "node",
    args = {os.getenv("HOME") .. "/code/vscode-node-debug2/out/src/nodeDebug.js"}
}

vim.fn.sign_define("DapBreakpoint", {text = "🛑", texthl = "", linehl = "", numhl = ""})
vim.fn.sign_define("DapStopped", {text = "🟢", texthl = "", linehl = "", numhl = ""})

dap.configurations.typescript = {
    {
        type = "node2",
        request = "attach",
        program = "${file}",
        cwd = vim.fn.getcwd(),
        sourceMaps = true,
        protocol = "inspector"
    }
}

require("dapui").setup()

this is how i attach with lazyloading

local function attach()
    print("attaching")
    if not packer_plugins["nvim-dap"].loaded then
        vim.cmd [[packadd nvim-dap]]
        vim.cmd [[packadd nvim-dap-ui]]
    end
    require("plugins.dap")
    local dap = require "dap"
    dap.run(
        {
            type = "node2",
            request = "attach",
            cwd = vim.fn.getcwd(),
            sourceMaps = true,
            protocol = "inspector",
            skipFiles = {"<node_internals>/**/*.ts"}
        }
    )
end

return {
    attach = attach
}

when nvim loads it wont load dap or dapui
when i press my mapping to trigger the attach() function dap and dapui gets loaded

flow is as follows:

1. Run Neovim
2. press space d h l - to attach to debugger
3. set breakpoints
4. trigger something in app to hit breakpoint
5. when app reaches breakpoint the errors pop up

I would like to apply Onedark.nvim highlight on the panel. I read this issue but there isn't a real fix

I have the following configuration:

dapui.setup({
  floating = {
    mappings = {
      close = { '<C-d>' },
    },
  },
})

Pressing <C-d> is able to close floats which have elements such as scopes, but if the floating element is repl, it does not close when I press <C-d>, I instead have to press <C-w> and switch to another split.

I'd like to create some custom buffer-local mappings inside the dapui elements, just for convenience (e.g., taking a hint from spice.vim, i'm mapping r to go to repl, w to go to watches, …). I am currently using the following patch just to see if the idea can be made to work, with

require('dapui').setup({
  custom_mappings = {
    { "n", "<leader>w", "<cmd>1wincmd w<CR>", { noremap = true } },
    { … },
  },
})

diff --git a/lua/dapui/config/init.lua b/lua/dapui/config/init.lua
index 1ed4ff0..7dd316a 100644
--- a/lua/dapui/config/init.lua
+++ b/lua/dapui/config/init.lua
@@ -61,6 +61,7 @@ local default_config = {
     },
   },
   windows = { indent = 1 },
+  custom_mappings = {},
 }

 local user_config = {}
@@ -91,6 +92,7 @@ function M.setup(config)
   local filled = vim.tbl_deep_extend("keep", config or {}, default_config)
   filled.mappings = fill_mappings(filled.mappings)
   filled.floating.mappings = fill_mappings(filled.floating.mappings)
+  filled.custom_mappings = filled.custom_mappings or {}
   filled.sidebar = fill_elements(filled.sidebar)
   filled.tray = fill_elements(filled.tray)
   user_config = filled
@@ -121,4 +123,8 @@ function M.windows()
   return user_config.windows
 end

+function M.custom_mappings()
+  return user_config.custom_mappings
+end
+
 return M
diff --git a/lua/dapui/render/state.lua b/lua/dapui/render/state.lua
index a3e36fc..6130342 100644
--- a/lua/dapui/render/state.lua
+++ b/lua/dapui/render/state.lua
@@ -170,6 +170,9 @@ function M.render_buffer(state, buffer)
     api.nvim_buf_set_option(buffer, "modifiable", false)
     api.nvim_buf_set_option(buffer, "buftype", "nofile")
   end
+  for _, t in pairs(config.custom_mappings()) do
+      api.nvim_buf_set_keymap(buffer, unpack(t))
+  end
   return true
 end

This does work for me, but it's fragile because it depends on the windows being laid out on screen in a certain way (the default, I didn't bother to change anything). If you're at all interested in the idea, do you have any advice on how to do it more nicely?

The init window layout:

It would be great if path in stack and threads window would have shorter lengths (maybe as an option):

This way user could see the line number.
One way would be to use file path relative to current project directory:

rel_file_path = vim.fn.expand("%:p:~:.")

Based on - http://vimdoc.sourceforge.net/htmldoc/cmdline.html#filename-modifiers

Another thing - it would be cool if in stack window - would take us to selected line in stack/thread file.

On nvim-dap-ui .close(), every dap-ui thing gets closed except for the debugee's output's terminal (I'm using terminalKind = 'integrated' on vscode's bashdb wrapper configured for nvim-dap).

I wished to have a nvim-dap-ui option for auto closing this dangling terminal on its TermClose.

Context: neovim/neovim#14986 (comment)

You can check problem by the url.
https://asciinema.org/a/bPbXj3FHo8efSwGphQeLAuTOL

When the floating window height is set to a large number, e.g. 1.0, or 0.9, I would expect it to fill the grow up to this size to show all variables if possible.

The recording here shows that it could grow slightly to show all the variables but it doesn't, giving the impression that the height value is being ignored.

nvim-dap supports jumping to the frame using the REPL as mentioned in the below comment
mfussenegger/nvim-dap#6 (comment)

Is it possible to do the same using the "Stack" Element?

I could see that the open mapping would move the cursor to the stack location, but it does not update the Scope variables and the cursor positions

Is there a function I can call to move my cursor to the Scopes window? Or any of the debug windows?

When hovering over a variable (reference to some object), and doing :lua require'dapui'.eval(), a popup window containing a single integer shows up. I can't find any sort of relationship between that integer and the actual value of the object.

This is really a shame becasue dap.ui.variables.hover() gives great results, but the window behavior is weird. dapui.eval() has fantastic window behaviour, but the actual results make no sense.

executing :lua require'dapui'.float_element("repl") does not appear to open a reply but just a blank floating window.

asciicinema

You can find detailed information here.pocco81/dap-buddy.nvim#4

Here is the relevant details on my setup:

DAP config in init.lua:

local dap = require('dap')
dap.adapters.python = {
  type = 'executable';
  command = os.getenv('USERPROFILE') .. '\\AppData\\Local\\nvim\\debugpy\\Scripts\\python.exe';
  args = { '-m', 'debugpy.adapter' };
}
dap.configurations.python = {
  {
    type = 'python';
    request = 'launch';
    name = "Launch file";
    program = "${file}";
    pythonPath = vim.fn.getcwd() .. '\\.venv\\Scripts\\python.exe';
    console = 'integratedTerminal';
  },
}
require('dapui').setup()

Output of :version:

NVIM v0.5.0-dev+1233-g82ac44d01
Build type: RelWithDebInfo
LuaJIT 2.1.0-beta3
Compilation: C:/Program Files (x86)/Microsoft Visual Studio/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx86/x64/cl.exe /DWIN32 /D_WINDOWS /W3 /MD /Zi /O2 /Ob1 /DNDEBUG /W3 -D_CRT_SECURE_NO_WARNINGS -D_CRT_NONSTDC_NO_DEPRECATE -DWIN32 -D_WIN32_WINNT=0x0600 -DINCLUDE_GENERATED_DECLARATIONS -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -DMIN_LOG_LEVEL=3 -ID:/a/neovim/neovim/build/config -ID:/a/neovim/neovim/src -IC:/projects/nvim-deps/usr/include -ID:/a/neovim/neovim/build/src/nvim/auto -ID:/a/neovim/neovim/build/include
Compiled by runneradmin@fv-az152-151

Features: -acl +iconv +tui
See ":help feature-compile"

   system vimrc file: "$VIM\sysinit.vim"
  fall-back for $VIM: "C:/Program Files/nvim/share/nvim"

Run :checkhealth for more info

starting the DAP with :lua require('dap').continue() works wonderfully, and all the windows are properly setup. The DAP repl works great and as expected also. When .exit is executed at the repl, though, things break down. I added print(vim.inspect(sidebar_windows)) and print(vim.inspect(tray_windows)) here and here, and here is the output when .exit is run at the repl:

{
  [1003] = {
    float_defaults = {
      enter = true,
      height = 20,
      width = 80
    },
    name = "DAP REPL",
    on_close = <function 1>,
    on_open = <function 2>,
    setup = <function 3>
  }
}
Error executing vim.schedule lua callback: ...ata\Local\nvim\plugged\nvim-dap-ui\lua\dapui\windows.lua:47: Invalid window id: 1003
{
  [1003] = {
    float_defaults = {
      enter = true,
      height = 20,
      width = 80
    },
    name = "DAP REPL",
    on_close = <function 1>,
    on_open = <function 2>,
    setup = <function 3>
  }
}
Error executing vim.schedule lua callback: ...ata\Local\nvim\plugged\nvim-dap-ui\lua\dapui\windows.lua:47: Invalid window id: 1003
Press ENTER or type command to continue

I haven't dug into it too much further than that, but maybe can over the weekend. I'm no lua pro, though. I figured I'd get it in front of you first. Few things I'm confused about:

1. 1003 is showing up in both the sidebar and tray window tables
2. None of the other windows are showing up in either table
3. 1003 appears to be a valid window id, so I'm not sure why nvim is complaining about an invalid window id.

I know windows is probably not your target platform, so let me know if I need to do any more testing to help with this.

And forgot to add: thanks so much for putting this together. Can't wait to switch to this from pdb and vimspector. I really like the UI you've put together.

Is it possible to disable the status line for windows DapUI makes?

Like can you call set statusline=\ after the window is created?

or maybe something like:

au BufEnter,BufWinEnter,WinEnter,CmdwinEnter * if bufname('%') == "DAPUI_WATCHES" | set laststatus=0 | else | set laststatus=2 | endif

etc. for each win name (stacks, breakpoints, scopes, etc.)?

It would be great to be able to do something like this:

dapui.float_element('breakpoints', true) -- automatically jump

Or this:

dapui.float_element('breakpoints', { jump: true }) -- automatically jump

Rather than having to call the function twice:

dapui.float_element('breakpoints'); dapui.float_element('breakpoints')

repl output are useful some time, plz follow nvim-dap repl output

Error info:

Error executing vim.schedule lua callback: .../.vim/plugged/nvim-dap-ui/lua/dapui/elements/watches.lua:19: attempt to index field 'error' (a nil value)

The error message is similar to the previous one.
#22 (comment)

Hi there,

Would be awesome if we could specify sidebar window configuration. In my opinion, variables should consume much more space than e.g. threads, so I'd like to specify this via config, though I can see that right now it just does splits without specifying the size. Version 2.0 of this feature would allow for persistence of manually resized (e.g. restarting the UI on the same file because I changed the code would not change the window layout which I have adapted in previous run to be well suited to debugging the current setup)

Thanks a ton for this awesome plugin!

I get this in error log:

Removing nvim-dap-if fixes the issue. All other plugins seems to work ok

I have a very wide screen and would prefer to have the REPL in a separate column next to the sidebar (with default contents). But it looks like right now that isn't possible-- you either use the tray or have to place the REPL inside a single-column sidebar.

Would you consider making it possible to use two columns?

Hi,

This idea came out of mfussenegger/nvim-dap#185.

I think it would be very helpful to have a pane showing all active breakpoints. as far as I can tell this isn't available yet as an element. A desired solution would show me breakpoint file number and line and allow easy jumping to it, e.g. via enter/o key

local elements = {
  STACKS = "stacks",
  SCOPES = "scopes",
  REPL = "repl",
  WATCHES = "watches"
}

Using the setup configuration to override default keymaps doesn't work for me.

require("dapui").setup({
  mappings = {..}

Let me know if there's any info I can provide to help you debug. Thanks!

The README states that to activate the floating window you call require("dapui").float_element(<element ID>). In the README an example element ID is stacks. So I execute require("dapui").float_element(stacks). This then prompts me for an element ID again, however, it seems to only take numbers, I tried using numbers 1-10 but nothing happened. My expectation is that by executing require("dapui").float_element(stacks) an additional prompt would not appear and instead just the floating window would.

It's possible to highlight a UI window (e.g. dap_stacks) and change the buffer displayed within. Such behaviour is forbidden in, say, NvimTree. I think it makes sense here, too.

I would be great if user could edit existing watch

I got error messages when starting nvim-dap (and "step over", ...):

Error executing vim.schedule lua callback: ...im/site/pack/packer/start/nvim-dap-ui/lua/dapui/util.lua:6: attempt to index local 'path' (a nil value)

And more:

Despite the error messages, dap-ui works well except the "DAP Stacks" window:

I could fix(?) them by adding the following line to the first of function util.pretty_name(path):

function M.pretty_name(path)
  if path == nil then return "" end
  -- ...

Or this to the first of function util.is_uri(path):

function M.is_uri(path)
  if path == nil then return false end
  -- ...

My configs:

local dap = require("dap")

dap.adapters.rust = {
  type = "executable",
  attach = {pidProperty = "pid", pidSelect = "ask"},
  command = "lldb-vscode",
  env = {LLDB_LAUNCH_FLAG_LAUNCH_IN_TTY = "YES"},
}

dap.configurations.rust = {
  {
    type = "rust",
    request = "launch",
    name = "lldb",

    program = function()
      local metadata_json = vim.fn.system("cargo metadata --format-version 1 --no-deps")
      local metadata = require("lib.json").decode(metadata_json)
      local target_name = metadata.packages[1].targets[1].name
      local target_dir = metadata.target_directory
      return target_dir .. "/debug/" .. target_name
    end,
  },
}

require("dapui").setup {icons = {expanded = "", collapsed = ""}}

My envs:

• NVIM v0.5.0-dev+nightly-656-g2a1bc8657
• lldb version 12.0.0
• cargo 1.54.0-nightly (e51522ab3 2021-05-07)
• rustc 1.54.0-nightly (ca82264ec 2021-05-09)
• macOS 11.4 / MacBook Pro 2019

Thank you for the great extention!

In VSCode debugger, when a variable's value changes, the whole thing gets highlighted, like in the picture below.
That would be a very nice enhancement to add imo.

Hi! First of all, congratulations on the amazing plugin!

I just tried out the eval feature. Having the variable value in a floating window is great, but I can't close it easily.
I need to focus it (by clicking, or triggering eval a second time) and :q.

One would expect the window to close on cursor movement, except if it has been focused!

(also, the window is always on the top left corner of the screen... one would expect it to be under the cursor, but it's not a big deal)

What do you think?

Thank you for your fantastic work.

In the scope window the only 'actionable' items are those that are expandable. It would be a small efficiency improvement if pressing 'j' or 'k' jumped to lines which are actionable. At the moment relative jumps is probably the fastest way but I feel like this would make variable inspection faster

An example in the picture would be if I press j, it would jump from line 7 to line 23. Everything in between is already visible and cant be expanded anymore.

I'm not sure if something like this is feasible as it would stop other things being possible e.g. yanking variables or something like that, but maybe this could be toggleable. Just an idea anyways.

Alternatively if could be a keymapping where jumps to next actionable etc.

This problem may be similar to the one I encountered in nvim-dap repl.
mfussenegger/nvim-dap#119

When I run:
require'dap'.stop() or require'dap'.disconnect() - added in latest docs commit : https://github.com/mfussenegger/nvim-dap/commits/master/doc/dap.txt
Dap UI wont close. Is there change you could @rcarriga expose function ui_dap_close() - so that It could be called manually (in case auto close wont work) ?

The moment debugging stops all windows automatically close. If we are currently in insert mode in the REPL window (i.e step through the entire program (NOT IF .exit is executed)) we are thrown into insert mode in the code window.
Now the real problem is the fact that the stuff you accidentally inserted isn't undoable.
Don't know if this is a bug by neovim (im on v0.5.0-dev+1423-ge2d3ad7bc)
However i've managed to fix this by manually going into normal mode after the window closes. Inserting this

function M.on_close()
    local key = vim.api.nvim_replace_termcodes("<Esc>", true, false, true)
    vim.api.nvim_feedkeys(key, 'n', true)
end

into

I'm geting the folowing error

Automatically opening the UI is deprecated.
You can replicate previous behaviour by adding the following to your config

local dap, dapui = require('dap'), require('dapui')
dap.listeners.after.event_initialized['dapui_config'] = function() dapui.open() end
dap.listeners.before.event_terminated['dapui_config'] = function() dapui.close() end
dap.listeners.before.event_exited['dapui_config'] = function() dapui.close() end

To hide this message, remove the `open_on_start` settings from your config

Is there way to add mouse double click as additional mapping to expand selected item (so that we can use both Ret and 2Click for expand/collapse)?

I can't bind the custom highlights locally since you're overwriting them and don't use a GUI version of neovim, so the GUI layer shows up as nothing here. So any chance you can map these colors back to some default defined highlight groups and use your custom overrides locally?

Then rerunning a debugging run (dap.stop(), then restart), I always encounter an error. Re-opening nvim everytime is a bit laborious.

Error executing vim.schedule lua callback: vim/shared.lua:423: s: expected string, got nil
stack traceback:
        vim/shared.lua:423: in function 'trim'
        ...m/plugged/nvim-dap-ui/lua/dapui/elements/breakpoints.lua:30: in function 'render_breakpoints'
        ...m/plugged/nvim-dap-ui/lua/dapui/elements/breakpoints.lua:78: in function 'render'
        ...m/plugged/nvim-dap-ui/lua/dapui/elements/breakpoints.lua:100: in function 'refresh_breakpoints'
        ...m/plugged/nvim-dap-ui/lua/dapui/elements/breakpoints.lua:127: in function 'on_open'
        .../yingzhu/.vim/plugged/nvim-dap-ui/lua/dapui/windows.lua:33: in function 'open_wins'
        .../yingzhu/.vim/plugged/nvim-dap-ui/lua/dapui/windows.lua:61: in function 'open_sidebar'
        /Users/yingzhu/.vim/plugged/nvim-dap-ui/lua/dapui.lua:156: in function 'open'
        /Users/yingzhu/.vim/plugged/nvim-dap-ui/lua/dapui.lua:127: in function 'c'
        /Users/yingzhu/.vim/plugged/nvim-dap/lua/dap/session.lua:539: in function </Users/yingzhu/.vim/plugged/nvim-dap/lua/dap/session.lua:527>

Whenever I step over a line that changes the elements of an arrary, the values are not updated in the Locals sidebar.

This is only for elements within an array. All other locals like a normal integers are updated automatically.

Currently I have to close the drop down and open again to see the updates.

I am debugging C++ on NVIM v0.5.0-dev+nightly.

Backspace can't delele character in watch window.
#31
mfussenegger/nvim-dap#119
neovim/neovim#14116
I think nvim-dap-ui should add some code for temporary workarround just like nvim-dap.
mfussenegger/nvim-dap#120
mfussenegger/nvim-dap#123

The screenshots in the readme look very appealing, however I am not able to reproduce them on my local setup. There are no discernible highlights out-of-the-box (see screenshot), and it is unclear how to configure them (if possible at all). The highlights in dapui.highlights don't seem to have any effect, or am I missing something? I am loading my colorscheme (gruvbox-material) prior to requiring dapui.

Highlighting is very important here imo, since the naturally narrow windows clutter up very quickly (I artificially widened the above screenshot for clarity):

What is the canonical way to set these highlights? Maybe it is even possible to simply link to tree-sitter groups, such that tree-sitter aware colorschemes can benefit from this without cost?

When UI is toggled on, the REPL becomes cleared. It would be preferable to have the REPL be persistent.

When opening the REPL using :lua require("dap").repl.open() the REPL does not clear. It only clears when opening using :lua require("dapui").toggle()

Edit: It looks like :lua require("dap").repl.close() is what clears the REPL. Using that function closes the split and clears the history. But just closing the split with :q does not clear the history, such that when re-opening the contents will still be there.

So perhaps I should report this to nvim-dap instead.

Edit 2: Turns out you can call repl.close({ mode="toggle" }) to close the repl without clearing its contents. So this can be fixed within nvim-dap-ui. I'll put up a PR shortly in case this is something you'd be interested in accepting.

Variables added to a watch are not automatically updated in the watch window. I have to go back to the watch window and re-add the variable for it to update.

Here is my configuration

require("dapui").setup()
require('dap-python').setup('~/miniconda3/envs/debugpy/bin/python')

If I add a watch variable to tmp in the following code, tmp stays at 0 throughout the loop rather than being incremented (see screenshot below).

for i in range(10):
    tmp = i
    print(tmp)

When adding or removing breakpoints, the breakpoint widget immediately updates. However, when there is only one breakpoint, removing it will not remove it from the breakpoint widget.

Attached is a video demonstrating the issue.
https://user-images.githubusercontent.com/12166320/131056673-55db2f3e-7961-4246-b858-4c7e45ba8347.mov

First, I wanna thank you for the awesome plugin.

As you can see in my screenshot, when my cursor is in a floating window, I must type :q to quit. When I use native LSP, they added keymap q to close the floating window more natural.
I can add mapping to vimrc like this:

autocmd FileType dapui_hover nnoremap <buffer> <silent> a :bdelete<cr>

But I think set buffer keymap in plugin's Float window is better.
Hope I can add that keymap to your plugin and it will be configurable:

  mappings = {
    close_floating = {"<Esc>", "q"},
  }

If you agree, I will create PR for this. Thank you!