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/202004131545.03DFjD5U009582%40masaka.moolenaar.net.
