Hi Bram,

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

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.)

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.

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)
- 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.
- 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)
- 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.

Kind regards,
Ben

-- 
-- 
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/4dedd56e-1347-4c1b-b9d6-291a1e15e77b%40googlegroups.com.

Raspunde prin e-mail lui