No sections in nvim 0.11.2

[paulhdk]

Is the nightly still a hard requirement?

When running with nvim stable 0.11.2, a dap-view-term buffer opens with no contents. All the sections appear to be missing.
Does anyone have any pointers?

[igorlfs]

Is the nightly still a hard requirement?

Nope, nviim 0.11 should be working just fine.

When running with nvim stable 0.11.2, a dap-view-term buffer opens with no contents. All the sections appear to be missing.
Does anyone have any pointers?

Please, share details. Most importantly, your config.

[paulhdk]

Thank you for your quick reply!

[...]

When running with nvim stable 0.11.2, a dap-view-term buffer opens with no contents. All the sections appear to be missing.
Does anyone have any pointers?

Please, share details. Most importantly, your config.

Which config are you interested in particular?
I just disabled all my plugins except for telescope and dap + dap-view and am still seeing the issue.

dap and dap-view are both using default options.

I'm using lldb-dap for debugging.

[igorlfs]

Hey, sorry for the delay

Which config are you interested in particular?

Can you create a minimal init.lua? Nothing fancy, you can use the following as a template:

vim.env.LAZY_STDPATH = ".repro"
load(vim.fn.system("curl -s https://raw.githubusercontent.com/folke/lazy.nvim/main/bootstrap.lua"))()

---@diagnostic disable-next-line: missing-fields
require("lazy.minit").repro({
	spec = {
		{
			"mfussenegger/nvim-dap",
			dependencies = "igorlfs/nvim-dap-view",
			config = function()
				-- TODO minimal stuff necessary for the repro
			end,
		},
	},
})

[paulhdk]

With the following config and test file, nvim-dap-view isn't showing at all for me. Probably I'm missing something obvious?

Steps to reproduce:

1. repro.lua and example.cpp in same folder, clang and lldb-dap in PATH.
2. nvim -u repro.lua -- example.cpp
3. Go to one of the prints
4. \sb
5. F5
6. nvim-dap-view doesn't open.

repro.lua:

vim.env.LAZY_STDPATH = ".repro"
load(vim.fn.system("curl -s https://raw.githubusercontent.com/folke/lazy.nvim/main/bootstrap.lua"))()

---@diagnostic disable-next-line: missing-fields
require("lazy.minit").repro({
	spec = {
		{
			"mfussenegger/nvim-dap",
			dependencies = {
				"igorlfs/nvim-dap-view",
			},
			config = function(_, _)
				local dap = require("dap")

				dap.adapters.lldb = {
					type = "executable",
					command = "/usr/local/bin/lldb-dap",
					name = "lldb",
				}

				dap.configurations.cpp = {
					{
						name = "Launch (File)",
						type = "lldb",
						request = "launch",
						program = function()
							os.execute("clang -g example.cpp")
							return vim.fn.getcwd() .. "/a.out"
						end,
						cwd = "${workspaceFolder}",
						stopOnEntry = false,
						args = {},
					},
				}
			end,
			keys = {
				{
					"<F5>",
					function()
						require("dap").continue()
					end,
				},
				{
					"<Leader>sb",
					function()
						require("dap").toggle_breakpoint()
					end,
				},
			},
		},
	},
})

example.cpp:

#include <cstdio>

int main() {
  printf("Hello ");
  printf("World");
}

[igorlfs]

Probably I'm missing something obvious?

Indeed!

...
6. nvim-dap-view doesn't open.

By default, nvim-dap-view does not launch when starting a new session. You have to manually call :DapViewToggle (or :DapViewOpen). Of course, you can enable auto launching: see this section in the documentation.

Let me know if this solves your issue!

[paulhdk]

[...]
6. nvim-dap-view doesn't open.

By default, nvim-dap-view does not launch when starting a new session. You have to manually call :DapViewToggle (or :DapViewOpen). Of course, you can enable auto launching: see this section in the documentation.

Let me know if this solves your issue!

Ah. I missed that. Works now. Thanks!

Wouldn't it make sense to mention that more prominently in the README or documentation? Would you welcome a PR here? Especially since the terminal dap-view-term does open automatically, which I personally find misleading, but maybe there is again an obvious reason I'm missing.

Thank you for your help so far!

[igorlfs]

Wouldn't it make sense to mention that more prominently in the README or documentation?

It does! And that's what I did in the latest commit, 21ae3b5. If you think it's not enough, PR welcome!

there is again an obvious reason I'm missing.

I can see how it sounds misleading. The reason why it behaves that way is to match nvim-dap's out of the box behavior: if you're not using any UI plugins, the terminal (generally) spawns. When I was implementing that feature, that was the rationale anyways. But back then, the plugin was a lot simpler. There's an option to change this behavior, we could switch its default value if that makes more sense now. What do you think?

I guess an argument against it is that with the current API it's difficult to open just the console. But as of right now, I'm favorable to this change due to its UX implications. If you're feeling like it, you can comment on the issue for suggestions for breaking changes, to raise more visibility to this matter.

[paulhdk]

Wouldn't it make sense to mention that more prominently in the README or documentation?

It does! And that's what I did in the latest commit, 21ae3b5. If you think it's not enough, PR welcome!

Nice!

there is again an obvious reason I'm missing.

I can see how it sounds misleading. The reason why it behaves that way is to match nvim-dap's out of the box behavior: if you're not using any UI plugins, the terminal (generally) spawns. When I was implementing that feature, that was the rationale anyways. But back then, the plugin was a lot simpler. There's an option to change this behavior, we could switch its default value if that makes more sense now. What do you think?

I guess an argument against it is that with the current API it's difficult to open just the console.

Merging the terminal with the other UI and selecting it through the tab bar would get you closest, I guess?

But as of right now, I'm favorable to this change due to its UX implications. If you're feeling like it, you can comment on the issue for suggestions for breaking changes, to raise more visibility to this matter.

Given that the default config in the README doesn't set any options, I just assumed it was going to work as expected out of the box.
Now, "as expected" is going to be different for everyone of course.
For me it meant getting the whole UI, especially since I never saw any mention of toggle commands etc.
I'd venture a guess and say that most people installing this plugin are interested in having a UI. But I can't back that claim up with numbers of course :)
I'd personally even going as far as saying that I'd expect the terminal to to be integrated into the tab bar by default, but that's really just preference I think.

So, I'm in favour of enabling the UI by default and then mentioning in the documentation that it can also be toggled.
I'll post that in the other thread too 👍🏻

[igorlfs]

Merging the terminal with the other UI and selecting it through the tab bar would get you closest, I guess?

That's currently possible, by adding "console" to your winbar.sections (which, again, could be a default).

For me it meant getting the whole UI, especially since I never saw any mention of toggle commands etc.

Thanks for letting me know that! The whole documentation was hosted on the README, but it was getting gigantic, so I moved everything to GitHub pages. In hindsight, that was a bad choice, since it's easier to skim through the README than to click a link to check the docs. I'll move the essentials back to the README!

I'd venture a guess and say that most people installing this plugin are interested in having a UI

Yeah, definitely, no doubt about that!

I'd personally even going as far as saying that I'd expect the terminal to to be integrated into the tab bar by default

I'll create a poll and link it to the v2 issue!

enabling the UI by default

That is something I'm strongly against. From what I can tell, taking a peek at people's public dotfiles, it's a fairly common preference. However, I feel it makes the most sense to keep the UI as unintrusive as possible (you could say it's of the project's "goals"). I myself rarely toggle the UI, only when I actually need it.

We could, however, simplify the setup for the auto toggle. It could be a boolean option.