Termdebug: add frames window and :Frames, similar to :Asm

[GitMensch]

A new window for showing the current frames and highlight (similar to the assembler window) the current place would be nice :-) Likely more often used than the assembly window (which is definitely cool to have, too).

I assume that this would share much of the dissasembly code but using backtrace command instead of dissasembly.

[lacygoill]

This is just a suggestion as I'm not familiar enough neither with debugging, nor with this new window, but if you think you end up with too many windows, you might be interested in a popup window, because the latter can be displayed over the others, and can be toggled on and off (see :help popup_hide() and :help popup_show()). Although that would only be OK if you don't intend to focus it; i.e. you just want to be able to read some info.

You might also try to set every frame as an entry in the quickfix list (or the location list); this way, you could leverage all the builtin commands around the quickfix window like :cnext, :cfirst ... and friends.

[lacygoill]

You might also try to set every frame as an entry in the quickfix list (or the location list); this way, you could leverage all the builtin commands around the quickfix window like :cnext, :cfirst ... and friends.

On that front, you might be interested in :help getqflist-examples, :help setqflist-examples, and :help quickfix-window-function (a concrete example is given at the end of the page).

[GitMensch]

Popups would be space-wise interesting, but in one of my personal use cases not usable - #3208. (Or did I misinterpret that and a popup is totally different from balloons?)

I'm not very familiar with the quickfix support - but that is very likely the best way to handle :Frames with the builtin commands. Thanks for pointing this out and for adding the help pointers.

[lacygoill]

(Or did I misinterpret that and a popup is totally different from balloons?)

A popup is different than a balloon. See this Popup window gallery page on the wiki for a few screenshots and get an idea of what you could achieve.

[GitMensch]

@brammool: Are you ok with a Frames Window? You know, just asking before I work more on that...

@ all: With the quickfix list being "likely doable": would we still want an extra command for switching the frames #9234 or should this be dropped because the quickfix list will be usable for the navigation and "enough"?

[GitMensch]

@lacygoill after a bit of hacking the quickfix list I see that the commands are nice - but the list isn't usable (or I've missed something).
Reason: We don't want to ask vim go to the file on the given line (which is possible to parse from the response of -stack-list-frames), but we want to ask gdb to go to the frame (and from the resulting gdb mi information lead vim to go there. Otherwise we'd be in a frame and all :Evaluate will still go to the original frame.

Also, as the stack frame may be always open a :Frame 5 command would be useful in any case - no need to switch the window.

Any opinions and/or thoughts?

BTW: is there a reasonable syntax for a stacktrace or even the default GDB backtrace format for the Frames window?

[brammool]

@brammool: Are you ok with a Frames Window? You know, just asking before I work more on that...

What would be this window? The output of "where"? Would it be possible to navigate through frames?

…

-- hundred-and-one symptoms of being an internet addict: 99. The hum of a cooling fan and the click of keys is comforting to you. /// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\ /// \\\ \\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ /// \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[GitMensch]

Yes, the output of where, updated on each "stop" (so step, brreakpoint reached, ...).
I have navigation through frames implemented as :Up, :Down (both using cli commands as the extension currently doesn't keep track of the active frame) and :Frame N.

I would like to "somehow" use the frames-window for navigation, but I don't know how to achieve this (it is just a buffer with text), and my try with quickfix list ended in "gdb must select the frame, not vim the file".

[brammool]

Yes, the output of where, updated on each "stop" (so step, brreakpoint reached, ...). I have navigation through frames implemented as `:Up`, `:Down` (both using cli commands as the extension currently doesn't keep track of the active frame) and `:Frame N`. I _would like to_ "somehow" use the frames-window for navigation, but I don't know how to achieve this (it is just a buffer with text), and my try with quickfix list ended in "_gdb_ must select the frame, not _vim_ the file".

Using a quickfix window doesn't seem like the right solution, since it works quite differently. You can most likely use buffer-local mappings. E.g. to handle a mouse click or pressing Enter on a certain line (relating to a certain frame). Proabaly using 'buftype' "nofile". Sending the frame command to gdb should then result in Vim displaying the code there. That should already work.

…

-- To be rich is not the end, but only a change of worries. /// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\ /// \\\ \\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ /// \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[GitMensch]

"possible in general" != possible for me, yet;
but I try to polish the current "Frames" window (view only, but always up to date) and frame related commands, then do a PR.

I hope you can then add the buffer-local mappings (the features will be in as functions already) and, if I haven't done that already marking of the current frame.