Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Handling terminat buffers withouttermbuf_pooling#1523

igorlfs started this conversation inGeneral
Discussion options

Hello!

I'm finishing the implementation of multi-session support fornvim-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 thetermbuf_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 thecurrent session. That sucks, because users may wanna take a look at that bufferafter 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 statesand 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 thetermbuf_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

You must be logged in to vote

Replies: 3 comments 5 replies

Comment options

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?

You must be logged in to vote
1 reply
@igorlfs
Comment options

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.

Comment options

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

You must be logged in to vote
4 replies
@igorlfs
Comment options

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'sterminal_win_cmd. I actually don't need to control the buffersper se, but from a UI standpoint, I need to controlhow the terminal spawns (i.e., the window and its position), which is only possible byalso 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 usingbelowright new as the default behaviorwithout 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 thecurrent session). There's also no need to meddle with the pooling if nvim-dap just exposed the buffer bysession (e.g., viasession.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
Comment options

I can quickly speak to the issues I currently have withnvim-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 theconsole be the default tab when opening thenvim-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 usenvim-dap andnvim-dap-view everyday, so really excited seeing this issue have activity again! Thanks everyone :)

@igorlfs
Comment options

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 andigorlfs/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
Comment options

You can test it by switching to#1546 andigorlfs/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

Comment options

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.

You must be logged in to vote
0 replies
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Category
General
Labels
None yet
3 participants
@igorlfs@mfussenegger@Run1e

[8]ページ先頭

©2009-2025 Movatter.jp