feature: Align the stack trace elements and truncate the file path so it's easier to read the stack trace in the Threads and Breakpoints tab

[NickJAllen]

Did you check the docs?

• I have read all the docs

Is your feature request related to a problem? Please describe.

I think it would be more readable if the current stack trace elements (i.e the function names) lined up with each other and the start of the path was truncated (e.g with "..."). Usually the full directory path is not needed and more important is the current function which gets pushed off the screen when the path gets long.

Also it would be easier on the eyes to parse the stack trace if they lined up in columns. eg one column for path, one for line number, and one for the function name.

This plug-in is amazing though. Please keep up the excellent work.

Describe the solution you'd like

I think the stack trace having a more column based structure where each column lines up with be nicer. So one column for file path, one for line number, one for function name. The user could maybe even configure the order of these columns and define their weights.

Describe alternatives you've considered

I'm not aware of an alternative solution

Additional context

No response

[igorlfs]

Hey,

and the start of the path was truncated (e.g with "...")

In what conditions (exactly) should this happen?

which gets pushed off the screen when the path gets long

Maybe we could have set wrap by default?

Also it would be easier on the eyes to parse the stack trace if they lined up in columns.

From your image, I can see where you're coming from...

---

The user could maybe even configure the order of these columns and define their weights

I'm thinking about exposing one piece (or multiple) of the internal rendering. For instance, instead of setting the label as

nvim-dap-view/lua/dap-view/threads/view.lua

Lines 102 to 106 in 4b0adae

	local path = f.source and f.source.path
	local relative_path = path and vim.fn.fnamemodify(path, ":.") or ""
	local label = "\t" .. relative_path .. "|" .. f.line .. "|" .. f.name
	table.insert(acc, { label = label, id = f.id })

It could (optionally) be a "render" function that receives these parameters (relative path, frame line, frame name).

However, if that were the only piece exposed, it wouldn't solve the "alignment" problem (since you wouldn't know the padding beforehand). So an additional align setting would be necessary.

This "render" function would also make the highlighting awkward. Currently, the pipes (|) are used as delimiters for the highlighting. Maybe we could expect an array of objects as the return type for this new "render" function: each element would be a table of type {label_part: string, hl: string?}.

I'll play around with a POC and add it to #128

---

But do notice the main reason for the threads view to be the way it is, is for consistency with the breakpoints view: both show the same information in the exact same way. The fact that you haven't mentioned the breakpoints view at all in the OP, is a bit interesting. Do you think it's fine the way it is, or would rather have the same features there? Do you think both views should share the same default experience?

EDIT: Oh, and by the way, the inspiration for this style was the default quickfix list. Do you use it yourself? 'Cause I imagine it would have the same issues you're describing. Perhaps you use it with a quickfix "beautifier" or something that we could take inspiration from?

[NickJAllen]

Hey,

and the start of the path was truncated (e.g with "...")

In what conditions (exactly) should this happen?

Actually I think it would be better to have 4 columns instead of 3. So you would have function name, file name, line number, directory

The directory is the least important part and would be the full path to the file (without the file name). Usually the function/method name + file name + line number is more than enough context to know where you are. The directory is useful but totally fine if it is truncated I think and just goes off the screen to the right. Then there is no need for truncation and all the most important and relevant information is presented up front and very unlikely to not be fully visible.

I'm thinking about exposing one piece (or multiple) of the internal rendering. For instance, instead of setting the label as

nvim-dap-view/lua/dap-view/threads/view.lua

Lines 102 to 106 in 4b0adae

local path = f.source and f.source.path
local relative_path = path and vim.fn.fnamemodify(path, ":.") or ""
local label = "\t" .. relative_path .. "|" .. f.line .. "|" .. f.name

table.insert(acc, { label = label, id = f.id })
It could (optionally) be a "render" function that receives these parameters (relative path, frame line, frame name).

However, if that were the only piece exposed, it wouldn't solve the "alignment" problem (since you wouldn't know the padding beforehand). So an additional align setting would be necessary.

That's a great idea! Maybe if the configuration is based around columns and the user can the define a render function per column that would solve the alignment issue. But personally I think it's enough if the user can just change the order of the columns or potentially the weighting (but the latter is also not necessary if the columns auto fit the widest element to show)

But do notice the main reason for the threads view to be the way it is, is for consistency with the breakpoints view: both show the same information in the exact same way. The fact that you haven't mentioned the breakpoints view at all in the OP, is a bit interesting. Do you think it's fine the way it is, or would rather have the same features there? Do you think both views should share the same default experience?

Actually I don't really end up using the breakpoints view but I think that would be great if it showed it the same way with the alignment in columns. When I set a breakpoint the file name and line number are far less important to me than the function or method name so having that as the first column by default would be perfect.

EDIT: Oh, and by the way, the inspiration for this style was the default quickfix list. Do you use it yourself? 'Cause I imagine it would have the same issues you're describing. Perhaps you use it with a quickfix "beautifier" or something that we could take inspiration from?

I use the quickfix list a lot just not the raw nvim quickfix list but via quicker.nvim plug-in. Which incidentally lines up the data in columns.

The screenshots of this column alignment in Quicker.nvim really show how nice it is when the quickfix list aligns like this.

https://github.com/stevearc/quicker.nvim

It would be amazing if it looked somewhat like that in the Threads and Breakpoints tabs.