Questions on execution termination and printing to the dap-repl

[ibhagwan]

First, ty for this really wonderful plugin, I was able to set it up nicely to work when running lua require'dap'.continue() so I can avoid calling run_this() or the triple instance logistics (A+B+launch() instaces) and it works fairly well.

In case you're interested, my one-small-step-for-vimkind configuration can be found in my config's lua/plugins/dap/lua.lua.

Admittedly I haven't gotten deep into the code of this plugin yet but perhaps there are simple answers for my questions:

• Is there an easy way to know when the luafile <file> is done so I can shut down the server? I tried all nvim-dap events and none of them seem to fire when execution is done (e.g. event_terminated, event_stopped, etc), which brings me to the 2nd question/issue:

• Running continue when execution is done brings up the Session active, but not stopped at breakpoint prompt which requires to terminate before being able to run the debug configuration again, however sending terminate fails with E5560: vimL function must not be called in a lua loop callback at the call to vim.fn.sign_unplace.

I believe it is an issue with nvim-dap and opened the below PR which solves the issue:
mfussenegger/nvim-dap#486

• Is there a way to view lua print statements in the [dap-repl] buffer? when using a double instance setup (A being the DAP server) and running :luafile myscript.lua on A I am able to see the print statements output on the :messages of A but not in the [dap-repl] on B - is that a bug/setup issue or even possible?

[jbyuki]

I'll answer the questions to the best of my knowledge. It might be too late for you as you may have moved to other things but I'll leave it as a reference, because it's really good questions.

Know programmatically when luafile execution has finished

There is no real way to know it as you have properly diagnosed. The reason is that the debuggee process is the whole neovim instance and not just a script. When the neovim instance itself is terminated, there should be an event but that's all there is to it. I don't really see a way to archieve on per-script basis unless a flag is manually embedded in the script for example.

EDIT: Thinking about this a bit more, it would be possible to add a few lines to stop the osv adapter in the script if it's running. So adding require"osv".stop() at the end of the script would terminate the debugging session by itself.

print statements in [dap.repl]

This is again not implemented. It was mainly because of the technical limitations. I view this as a purely design feature because the output is already visible in the other debuggee instance. I'm assuming it's technically possible to do this. I have hijacked the lua print in one of my other plugin (see carrot.nvim), but the print is modified in another neovim instance, where as in this case, it has to be modified in the debuggee instance itself, I mean the trick is to redefine the print function. And also, it would not support nvim_echo so long story short, it may be possible, I don't see how, but it's currently not worth effort/gain.

[jbyuki]

In case you're interested, my one-small-step-for-vimkind configuration can be found in my config's lua/plugins/dap/lua.lua.

You might want to check out the new configuration I propose on the README. In the previous proposed configuration, it was kind of tedious to enter a port a debugging sessions is started so the current configuration avoids it by setting it to a fixed port number.

[ibhagwan]

In case you're interested, my one-small-step-for-vimkind configuration can be found in my config's lua/plugins/dap/lua.lua.

You might want to check out the new configuration I propose on the README. In the previous proposed configuration, it was kind of tedious to enter a port a debugging sessions is started so the current configuration avoids it by setting it to a fixed port number.

Does look much simpler indeed, ty @jbyuki will test it out when I get in the mood of trying our debugging again :)