Handling terminat buffers without termbuf_pooling

[igorlfs]

Hello!

I'm finishing the implementation of multi-session support for nvim-dap-view. The last piece of the puzzle is handling terminal buffers in an intuitive manner. Here's my current approach:

Whenever the session changes, I create a new terminal buffer for the new session if the following criteria are met:

1. There's no terminal for that session
2. The session does not have a parent (which should avoid creating unnecessary buffers)

I think that's a solid approach. However, when it comes to deleting these buffers, I'm having trouble. To get around the termbuf_pooling, I thought about deleting the buffers when a session ends. This works perfectly pooling-wise, but it has the huge drawback of... cleaning up the buffer for the current session. That sucks, because users may wanna take a look at that buffer after the session ends.

I can see people (rightfully) complaining if I were to push such a change, but I couldn't come up with anything more clever. I would have to keep track of the session states and if a given buffer is visible, so I wouldn't delete it straight away. Also, I'm afraid that if I were checking both of these conditions, my workaround for the termbuf_pooling would no longer work.

My goal with this discussion is to check if I haven't missed anything to make behavior more intuitive.

cc @miroshQa may also be interested

[Run1e]

Am I understanding correctly that this is about working around the current terminal buffer pooling? I would imagine any hacky workaround you can come up with is acceptable, and if anyone complains just explain proper functionality is relies on an upcoming fix/change in a dependency.

Alternatively wait before you release multi-session for nvim-dap-view?

[igorlfs]

Am I understanding correctly that this is about working around the current terminal buffer pooling?

Yep!

Alternatively wait before you release multi-session for nvim-dap-view?

Landed on main recently. The new behavior has this limitation, but it's an overall improvement, so it's better this way.

[mfussenegger]

Whenever the session changes, I create a new terminal buffer for the new session if the following criteria are met:

1. There's no terminal for that session
2. The session does not have a parent (which should avoid creating unnecessary buffers)

I think that's a solid approach. However, when it comes to deleting these buffers, I'm having trouble. To get around the termbuf_pooling, I thought about deleting the buffers when a session ends. This works perfectly pooling-wise, but it has the huge drawback of... cleaning up the buffer for the current session. That sucks, because users may wanna take a look at that buffer after the session ends.

What's the reason that you need to take control of creating the buffers and deleting them?

Not entirely opposed to give the option to opt-out of the pooling, but would be interesting to know more about the use-case/requirements

[igorlfs]

Hey,

Sorry for backlogging this into oblivion.

What's the reason that you need to take control of creating the buffers and deleting them?

This is mostly about overriding nvim-dap's terminal_win_cmd. I actually don't need to control the buffers per se, but from a UI standpoint, I need to control how the terminal spawns (i.e., the window and its position), which is only possible by also taking responsibility for the buffers.

Not entirely opposed to give the option to opt-out of the pooling, but would be interesting to know more about the use-case/requirements

I came to think that it's not the pooling that's at fault here. If we could have a way to prevent nvim-dap from using belowright new as the default behavior without having to worry about the buffers, we'd be halfway done. Essentially, my idea is to allow a "no op" terminal creation, where no window is opened, but the buffer is created internally by nvim-dap.

The other part of the problem is switching the terminal buffer when the session changes (i.e., show the terminal for the current session). There's also no need to meddle with the pooling if nvim-dap just exposed the buffer by session (e.g., via session.buf).

I believe a combination of these would suffice for UI-related plugins. What do you think?

Edit: got some promising results with a draft implementation. I'll open a PR after a cleanup.

Edit 2: PR - #1546

[Run1e]

I can quickly speak to the issues I currently have with nvim-dap-view for context:

• When a session closes (either through the debugger crashing or the debugee closing) the buffer immediately disappears, so I can't read through old (previous session) output
• It's currently not possible have the console be the default tab when opening the nvim-dap-view window
• Once upon a while, starting a new debug session has no console output and I have to restart nvim for it to work again

Not sure what the cleanest solution to these issues are, but I would imagine from my short time looking into solutions that completely taking control over the terminal buffer lifetime would make these issues solvable.

I use nvim-dap and nvim-dap-view everyday, so really excited seeing this issue have activity again! Thanks everyone :)

[igorlfs]

Hey @Run1e,

When a session closes (either through the debugger crashing or the debugee closing) the buffer immediately disappears, so I can't read through old (previous session) output

The goal of my PR (here, #1546) is to allow fixing exactly that on nvim-dap-view's side, without having to change the pooling behavior. You can test it by switching to #1546 and igorlfs/nvim-dap-view#108.

It's currently not possible have the console be the default tab when opening the nvim-dap-view window

What exactly would be shown if there was no session running? Can you please create a new discussion on nvim-dap-view about this, so we can investigate?

Once upon a while, starting a new debug session has no console output and I have to restart nvim for it to work again

Can you check if you can repro with the aforementioned PRs? I'll also implement a feature to navigate by session in the terminal, which should make navigating by session a bit easier (i.e., switching terminals). By the way, there's also a "sessions view" (which is just nvim-dap's session widget).

To avoid spamming the discussion here, if you're having trouble with something from nvim-dap-view specifically, please create a new discussion there.

[Run1e]

You can test it by switching to #1546 and igorlfs/nvim-dap-view#108.

Seems to work from my initial testing.

Can you please create a new discussion on nvim-dap-view about this, so we can investigate?

igorlfs/nvim-dap-view#109

Can you check if you can repro with the aforementioned PRs?

Will do, I'll try to remember to report back.

By the way, there's also a "sessions view" (which is just nvim-dap's session widget).

I use these two keymaps to select new sessions, and switch between them using the Snacks picker: https://gist.github.com/Run1e/15b453f2fa00ae59d7318a34a9caefa2

[Run1e]

What's the reason that you need to take control of creating the buffers and deleting them?

Not entirely opposed to give the option to opt-out of the pooling, but would be interesting to know more about the use-case/requirements

Weary of answering on @igorlfs's behalf (he knows more about the problem domain at this point), but the gist of it is that UI implementations might want to control how terminal buffers are associated with sessions.

For example, you might want to:

• Reuse the same terminal buffer for the same session configuration between sessions (so old output doesn't just disappear when restarting a session)
• Have control of when terminal buffers are deleted (so output doesn't just disappear when you stop or start another session)
• Always have control of which terminal buffers are associated with each session so you can show the terminal output of the active session and not have to guess around the internal nvim-dap pooling

You're probably already aware but I outlined the current problems in this comment: igorlfs/nvim-dap-view#51 (comment)

nvim-dap-view seems to have a hack (that I haven't looked extensively into (E: seems it just deletes buffers when a session closes, which isn't ideal)) which seems to somewhat alleviate these issues but it has come at a cost of usability, namely that you can't open the console pane until you start a session because nvim-dap-view doesn't know what terminal buffer to show yet, which also makes the UI not show the console pane when opened.

Not familiar enough with the current state to say what the best solution is, however the ability to disable the pooling does solve all of these issues, as it completely inverts control of terminal buffer lifetime management to nvim-dap-view.