Thanks, Bram. > On 13 Apr 2020, at 14:46, Bram Moolenaar <b...@moolenaar.net> wrote: > > > Ben Jackson wrote: > >> When we were discussing vim9script, I mentioned that an interface for >> external/graphical debuggers for vimscript would be useful. Your response >> at the time was: >> >>>>>> * provide a interface to a debug adapter to allow debugging of >> vimscript >>>>>> executing in a Vim instance (i.e. Vim Debug Adapter) >>>>> >>>>> Sure. >>> >>>> Woo \o/. Debugging vimscript with vimspector would be very kickass. >>>> I’m more than willing to put in hard graft to make this happen. >> >>> It's not really related to Vim9 script, could be an independend project. >> >> So, challenge accepted. Over the last few months I've been working on this >> and have a mostly working prototype. I have even recently used it to debug >> a real problem in a real vim plugin. >> >> Here's a >> demo: >> https://files.gitter.im/vimspector/Lobby/qnjv/vimspector-vimscript-demo.gif > > Looks very interesting! > >> What you can see in the demo: >> >> - I open a .vim file, set a breakpoint and launch vim in a terminal window >> (using vimsector) >> - Vim (in the terminal window) hits the breakpoint and vimspector jumps to >> the current line in my code >> - Using vimspector I can step throught the vimscript, inspect local, >> script, window, etc. variables and view the _full_ execution stack >> (including source's etc.) > > Do I get it right that vimspector is a Vim plugin?
Yep it’s a Debug Adapter Protocol _client_ in Vim - supports graphical debugging of any language that there’s an adapter for (i.e. anything VScode supports). DAP is like the debugging equivalent of LSP. All possible thanks to your incredible work on vim 8. > >> Very briefly, the way this works is the vim-under-debug delegates the debug >> command loop (in debug.c) to a vimscript function, implemented by my >> "vim-debug-adapter" plugin. This callback's job is to provide a single >> command to execute (such as "next" or "step" or an ex command, like 'break >> add'). It does this by having a channel, connected to a debug adapter in a >> "request one command" loop. Meanwhile the debug adapter can issue other >> requests, implemented in the channel's callback. > > That sounds like a nice mechanism. So it's mostly the same as the > existing debug code, but instead of prompting the user in the > Vim-under-debug itself the prompt goes over the channel. Yes, that’s exactly it. > > I haven't dug into this, but I assume the output of a command also goes > over the channel, thus the Vim-under-debug doesn't show any debug > output. Sort of, the usual debug output is mostly suppressed in vim-under-debug (it’s still printing the ‘breakpoint hit at file:line’), but that’s mostly just work-in-progress stuff. Regarding the result of evaluations, if the command run is, say, echom or redraw, it will be echo’d/redrawn in vim-under-debug, but the _return_ value of the evaluation is sent to the debugger over the channel. > >> In order to make all of this work, a fairly large amount of change is >> required in Vim, such as: >> >> - delegating command reading from the debugger loop >> (https://github.com/puremourning/vim/blob/debugger/src/debugger.c#L166-L216) > > This can be improved. Instead of hard coding the function name it could > be specified with a command: > :debugfunc MyDebugger > :debugfunc NONE Yes, absolutely, I was actually planning to make it an option (e.g. :set debughandler=FunctionName). This is just in the “still discovering what to solve next” phase. The option seemed easy to add so I left it for later. > >> - completing the implementation of estack to hold data for sourced files, >> ufuncs, auto commands, etc. - this allows a new function (debug_getstack) >> to get the full stack trace shown in the demo. Normally stack traces only >> include the latest run of ufunc calls. > > This can most likely be a separate change. I was working towards this > with the "exestack" stuff. Which was far from complete. Should also be > used for error messages and exceptions. Yes, that was the plan - pull this part of the change out (and maybe improve general backtraces too for day-to-day operations not involving the debugger) as the first step. > >> - adding some vimscript commands like `debug_getvariables( scope )`, >> `debug_eval( in_scope, expr )`, debug_getstack >> (https://github.com/puremourning/vim/blob/debugger/src/evalfunc.c#L58-L60) >> - adding a way to evaluate a command in a script context (as well as a >> function context) that isn't the top of the stack (essentially use the >> _full_ execution stack for debug_backtrace_level) > > This sounds similar to something as the "frame" command in gdb, to > change the debugger scope. It is, and I initially actually added debug_setframe, but in practice it was safer/easier in my testing to add a function to evaluate an expression in a specific frame (reason was that if the expression threw an exception it was hard to un-set this frame without things getting messed up). If you prefer the more general approach I’ll spend more time on that. > >> - changes to breakpoints so that you can set a file-line breakpoint >> _within_ a function such that it fires when the function executes, rather >> than only when it is defined (this is quite hairy at the moment) >> - probably a bunch of equivalent changes for vim9 (haven't tried this yet) >> >> The very-work-in-progress vim changes are here >> : https://github.com/puremourning/vim/compare/master...puremourning:debugger >> The runtime code that provides the interface to DAP is >> here: >> https://github.com/puremourning/vim-debug-adapter/blob/master/runtime/nub.vim >> >> (and the debug adapter >> itself: https://github.com/puremourning/vim-debug-adapter) >> >> So the purpose of this RFC is to see whether I should progress further down >> this route: >> >> - share the demo/prototype for visibility >> - get your appetite for merging a patch like this (I would push the changes >> in smaller tested pieces of course) >> - get your general thoughts on the approach above >> - gauge community reaction, thoughts, comments, insults etc. >> >> Thanks for everything. If the general reaction is positive, I'll make a >> proper plan and send some more detailed RFCs for the various aspects. > > I won't have much time to dig into the inners of this, but generally it > sounds like a good way to go. THanks ;) > The target audience will be plugin > writers, thus I would suggest to first get some feedback from them. > That probably requires making many things work, but it appears you > already have that. Sounds like a good idea. I did ask in #vim and a number of people were very interested, though overwhelmingly there was support for better backtraces anyway, so I’ll certainly complete that portion. > > How about writing a "Intro in Vim debugging" that plugin writers can > follow, a hands-on kind of training. Good plan! > > The implementation details can still change, I think it's important to > first check the boundaries of what can be done with the current > mechanism, what is needed for the debugging. > > -- > SECOND SOLDIER: It could be carried by an African swallow! > FIRST SOLDIER: Oh yes! An African swallow maybe ... but not a European > swallow. that's my point. > "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD > > /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ > /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ > \\\ an exciting new programming language -- http://www.Zimbu.org /// > \\\ help me help AIDS victims -- http://ICCF-Holland.org /// -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/937B8679-A1F4-46AF-9499-57BC16717CDF%40gmail.com.
