bug: Terminal for delve adapter displayed with "below" split

[catgoose]

Did you check docs and existing issues?

• I have read all the plugin docs
• I have searched the existing issues
• I have searched the existing issues of plugins related to this issue

Neovim version (nvim -v)

NVIM v0.11.0-dev-1738+g2c629ad13f

Operating system/version

Ubuntu 24.04.2 LTS

Describe the bug

My usecase is probably not the norm, but I use a bit of a workaround to make delve work with the dap terminal eventhough delve does not support the integrated terminal. I used to be able to start nvim-dap-view, grab winnr and bufnr from require("dap-view.state") and use those to run vim.job.start within the terminal.

https://github.com/catgoose/nvim/blob/main/lua/config/dap/go.lua

Before:

After 80381efd1d2684880e842fecbc215a38489a9ebf:

Steps To Reproduce

1. use latest commit
2. use my delve configuration
3. start debugger which will attempt to hijack the dap-view terminal

Expected Behavior

terminal should be displayed with split = left or right, not bottom

[igorlfs]

This might require a more throughout investigation. But over on #17, I am once again rewriting the logic to create the terminal (hopefully for the last time!).

A more longish-term solution could be to not hijack the terminal (either exposing a way to override the function that does this or having a setting to disable_hijack, which would require the user to create their own terminal_win_cmd)

[catgoose]

This could help. In my delve configuration:

...
-- use these to start job in terminal window
    local bufnr, winnr = h.get_dap_view_window()
    if not (bufnr and winnr) then
      bufnr, winnr = h.create_manual_window()
    end

function M.get_dap_view_window()
  local state_ok, state = pcall(require, "dap-view.state")
  if not state_ok then
    return nil, nil
  end
  ---@diagnostic disable-next-line: undefined-field
  local bufnr, winnr = state.term_bufnr, state.term_winnr
  if bufnr and winnr then
    return bufnr, winnr
  end
  require("dap-view").open()
  ---@diagnostic disable-next-line: undefined-field
  bufnr, winnr = state.term_bufnr, state.term_winnr
  return bufnr, winnr
end

As you can see if nvim-dap-view is already open, state will return a bufnr and winnr. If I remove the last bit and open nvim-dap-view before starting the debugger with DapContinue:

--  require("dap-view").open()
  ---@diagnostic disable-next-line: undefined-field
--  bufnr, winnr = state.term_bufnr, state.term_winnr
--  return bufnr, winnr

The terminal opens as expected and is running delve on the port I set.

So it seems that I am opening nvim-dap-view to get a bufnr and winnr and nvim-dap-view is detecting that my adapter doesn't not use an integrated terminal so it defaults to split = "below"? Does that seem right?

[catgoose]

Ignore my last reply, that only works with 7d75930dc7203eef924079df75c2393f4d3180d9. I was not on latest.

[igorlfs]

Now that #17 was merged, can you try again?

I'm afraid you no longer will be able to reliably get nvim-dap-view's term_winnr, since the window is now only created "when necessary" (i.e., it won't show up as a blank buffer if there's no session running).

Perhaps you can create the terminal window yourself?

[catgoose]

Let me see what I can do.

[catgoose]

Yeah it's kind of janky the way I've gotten it to sort of work.

local state = {
  bufnr = nil,
  winnr = nil,
}

    local dv_bufnr, dv_winnr = h.get_dap_view_window()
    if not (dv_bufnr and dv_winnr) then
      vim.notify("Failed to create manual window for dap adapter")
      return
    end
    if state.bufnr then -- this refers to my local state above, not your state module
      vim.api.nvim_buf_delete(state.bufnr, { force = true })
    end
    vim.api.nvim_buf_call(dv_bufnr, function()
      state.bufnr = vim.api.nvim_create_buf(true, false)
      state.winnr = vim.api.nvim_open_win(state.bufnr, false, {
        split = "right",
        win = dv_winnr,
        height = 10,
      })
      vim.api.nvim_buf_call(state.bufnr, function()
        local cmd = { "dlv", "dap", "-l", ("%s:%d"):format(host, port) }
        local jobid = vim.fn.jobstart(cmd, {
          term = true,
        })
        if jobid == 0 then
          vim.notify("Invalid arguments", vim.log.levels.ERROR)
          return
        elseif jobid == -1 then
          vim.notify(("Cmd `%s` is not executable"):format(cmd[1]), vim.log.levels.ERROR)
          return
        end
        vim.cmd("normal! G") -- tail the output without having to startinsert
      end)
    end)

Getting bufnr and winnr from your state, then using that to open a new terminal in right split and tracking the state of that bufnr in a local table. This works "ok", but some weird things happen.

If I don't have start_hidden = true this happens:

It actually creates the dap-view-term window!

If I set start_hidden = true:

1. When terminating debugger and starting again, the dap-view window at the bottom is 2-3 rows taller. If I terminate and run again, it reverts to correct size. It will just cycle like this.
2. I can't use dap-view toggle on the terminal because I created it and it's not managed by your plugin.

I'm sorry for the weird use-case, I know how it is. I maintain a few neovim plugins and there is always some joker with some weird ass request and I just think "please go away!". So sorry to be that guy! 👯

[igorlfs]

I'm sorry for the weird use-case, I know how it is. I maintain a few neovim plugins and there is always some joker with some weird ass request and I just think "please go away!". So sorry to be that guy! 👯

No worries! I'm sure we'll manage to find a working solution!

[catgoose]

I'm sorry for the weird use-case, I know how it is. I maintain a few neovim plugins and there is always some joker with some weird ass request and I just think "please go away!". So sorry to be that guy! 👯

No worries! I'm sure we'll manage to find a working solution!

I created a PR that exposes the bufnr/winnr of the created terminal and allows the terminal to be created before dap.session() to solve the bootstrapping problem.

[igorlfs]

Closed by #19

[igorlfs]

Reopening because I reverted the change that allowed this use case to work.

[igorlfs]

Hello! Can you confirm this issue is resolved with the latest commit, e42fd54?