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? > 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. 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. > 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 > - 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. > - 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. > - 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. 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. How about writing a "Intro in Vim debugging" that plugin writers can follow, a hands-on kind of training. 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 -- [email protected] -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/202004131346.03DDkWQW008791%40masaka.moolenaar.net.
