If the client sends a terminate the debug adapter can send the response,
terminate event and terminate the debug adapter process. In that case
the client immediately closed the stdout handle and cleared the message
callbacks table, preventing it from reliably processing the last few
messages.
This makes use of the async stdout:shutdown/client:shutdown to give it a
chance to process these last messages.
This is a follow up to
03807a4682
and should ensure that event_terminated listeners triggers happen in
most (all?) cases.
A debug adapter could exit the process before the client had an
opportunity to process the terminated response and event. In that case
`terminate` will timeout. The callback to `dap.terminate` should still
get triggered
This moves the ownership of the global session to the dap module.
Once multiple/hierarchical sessions are supported it is no longer safe
to reset the global session from within a session. It could cause a
child session to clear the reference to a parent session.
In preparation for multiple/hiearhical sessions which will be required
for the `startDebugging` reverse request.
With a global namespace we'd clear signs and diagnostics of all sessions
if one exits. That's a problem.
Allows users to distinguish between their own requests and other
requests when listening.
The motiviation for this is that nvim-dap maintains some state
internally for its functionality (e.g. session.current_frame) which
nvim-dap-ui needs to be aware of so users don't have issues with the two
plugins showing different information. Some of this state is set after
requests such as `stackTrace` for the current frame. nvim-dap-ui needs
to listen for this and refresh after it has been processed. Issues arise
when the listener causes more stack trace requests, leading to infinite
recursive calls because the listener can't distinguish between calls
made by nvim-dap and itself.
This is occurring now because of a large refactor of nvim-dap-ui which
moves away from maintaining state (which previously used the nvim-dap
request result) to making direct calls to the debugging adapter for all
data.
- Allow to switch current tabpage if the buffer is open in another tab
- Change current active window/buffer, if all else failed instead of
printing a warning
Swapping the session close and the reset of the namespace should fix the following error:
```
Error executing vim.schedule lua callback: /usr/share/nvim/runtime/lua/vim/diagnostic.lua:1458: Invalid buffer id: 22
stack traceback:
[C]: in function 'nvim_exec_autocmds'
/usr/share/nvim/runtime/lua/vim/diagnostic.lua:1458: in function 'reset'
/home/louis/.config/nvim/after/nvim-dap/lua/dap/session.lua:1399: in function 'close'
/home/louis/.config/nvim/after/nvim-dap/lua/dap/session.lua:703: in function 'callback'
/home/louis/.config/nvim/after/nvim-dap/lua/dap/session.lua:958: in function </home/louis/.config/nvim/after/nvim-dap/lua/dap/session.lua:950>
```
Signed-off-by: Louis DeLosSantos <louis.delos@gmail.com>
So far the exception info was shown in the REPL, but users may have the
REPL closed in which case they don't see the exception details.
This instead uses the diagnostic API to add the exception details as an
error.
There may not be a thread anymore for the `stopped_thread_id`.
That resulted in an error.
An alternative could be to reset the `stopped_thread_id` and assume it
is not stopped anymore, but not sure if that is safe.
