Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork247
-
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:
I think that's a solid approach. However, when it comes to deleting these buffers, I'm having trouble. To get around the 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 the 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 |
BetaWas this translation helpful?Give feedback.
All reactions
Replies: 3 comments 5 replies
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
-
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? |
BetaWas this translation helpful?Give feedback.
All reactions
-
Yep!
Landed on main recently. The new behavior has this limitation, but it's an overall improvement, so it's better this way. |
BetaWas this translation helpful?Give feedback.
All reactions
-
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 |
BetaWas this translation helpful?Give feedback.
All reactions
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
-
Hey, Sorry for backlogging this into oblivion.
This is mostly about overriding nvim-dap's
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 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., via 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 |
BetaWas this translation helpful?Give feedback.
All reactions
-
I can quickly speak to the issues I currently have with
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 |
BetaWas this translation helpful?Give feedback.
All reactions
❤️ 1
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
-
Hey@Run1e,
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.
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?
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. |
BetaWas this translation helpful?Give feedback.
All reactions
-
Seems to work from my initial testing.
Will do, I'll try to remember to report back.
I use these two keymaps to select new sessions, and switch between them using the Snacks picker:https://gist.github.com/Run1e/15b453f2fa00ae59d7318a34a9caefa2 |
BetaWas this translation helpful?Give feedback.
All reactions
👍 1
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
-
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:
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. |
BetaWas this translation helpful?Give feedback.
All reactions
❤️ 1