Waking up this thread, just to say that this is still work in progress. I actually use it quite often for my own debugging, but I'm holding off on patches for now while vim9script develops. I think it makes logical sense for this all to happen after vim9script is mature.
But as a teaser, I noticed that Bram added support for debugging vim9script statements yesterday, and so I've hooked that in to my prototype. So here's a demo of Vimspector debugging a simple vim9 script: https://asciinema.org/a/25SLL99WepcubhweLoQblz2Cg Lots more to do on this, but now the framework is in place. On Monday, April 13, 2020 at 4:45:23 PM UTC+1 Bram Moolenaar wrote: > > Ben Jackson wrote: > > [...] > > > > 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. > > Sounds like the message redirection should allow for redirecting to a > function, which would then send it over a channel. Currently it's > possible to redirect to a variable, it should be possible to redirect to > a callback function. > > > >> 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. > > Both would work. I was thinking of the symmetry with ":redir", it's > kind of redirecting the input. > > > >> - 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. > > I suppose setting the frame is something that exists in the remote > debugger. The API can include the frame in the evaluation command, > without changing the frame for following commands. > > > -- > ./configure > Checking whether build environment is sane ... > build environment is grinning and holding a spatula. Guess not. > > /// 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/9265c59d-b403-4194-b419-0c2ff9f1a1c9n%40googlegroups.com.
