Vscode: launching the debugger in tmux no longer works

[Mellbourn]

I have the setup that was described by João Moreno (@joaomoreno) in his blog post https://medium.com/@joaomoreno/persistent-terminal-sessions-in-vs-code-8fc469ed6b41
Whenever I open a terminal tab in VS Code, i enter a tmux session (often attaching to an already present tmux session)
I love this setup! Among other things, it allows all the window control of tmux and it enables me to restart VSCode without losing my terminal session.

Debugging has worked fine in this setup for a long time. With the setting "console": "integratedTerminal", the debugger starts inside the tmux shell, which is just what I want.

After 1.20.0, this has stopped working for me. When I start debugging by pressing F5, the debug command seems to flash briefly in the terminal tab, then it shows tmux. But the debugging never starts. (A new shell called Node Debug Console is created, but for me it just attaches to the same tmux session. May be what is happening is that the debug command is typed to the terminal window, but never executed because then the tmux session is attached).

Another hypothesis: Previously, I think there was a pause before the debug command started, which may have let the tmux session start so that the debug command could then run inside the tmux pane.

Thanks for an otherwise great product!

• VSCode Version: 1.20.1
• OS Version: macOS 10.13.3

Steps to Reproduce:

1. Have the tmux setup described in the blog post
2. Have a launch.config with "console": "integratedTerminal" (which worked previously)
3. Hit F5

Does this issue occur when all extensions are disabled?: Yes

[weinand]

The problem occurs in 1.20.0 because we've tried to fix https://github.com/Microsoft/vscode/issues/37589 by introducing a "busy check" (see https://github.com/Microsoft/vscode/issues/37589#issuecomment-357216349).

When using tmux, this checks always indicates the terminal is busy because tmux is already running. This results in a new terminal being created.

I will try to fix this by detecting whether "tmux" is running and in this case return "not busy". With this VS Code should use the old behaviour.

@Mellbourn please try this in tomorrows Insiders.

[weinand]

Reopened because my attempt to fix this only applies to linux and macOS.

[Mellbourn]

@weinand do you still want me to try tomorrows insider?

[weinand]

Sure, the fix should work on macOS (the bug was closed automatically by my commit; I could not prevent this...)

I'm not sure that "tmux" even exists (or is used) on Windows...

[weinand]

Please note that issue #37589 cannot be addressed when using "tmux".

[Mellbourn]

@weinand actually, if you can get debugging to work the way it did before in tmux, then #37589 not a problem for tmux.
Why? Because tmux has a much more powerful way to handle that challenge:
Once I have started a debugger inside tmux, and want to start another one, I just create another tmux pane in the same tmux window, and make sure that pane has focus. When I start the next debugger, it will be run in that pane.
I can now easily simultaneously see both debuggers running. I'm sure it works, because I've done it.

[weinand]

Yes, if you have a chance to switch the focus, you can launch multiple concurrent sessions.
But this approach doesn't work for "compound" launches. Here VS Code starts the sessions in rapid succession and you are not able to switch the focus in between.

[weinand]

It looks like that a native tmux does not exist for Window.
So I will close this issue then.

[Mellbourn]

Regarding tmux on windows:
I suspect it is not a common use case, but using Windows Subsystem for Linux you can actually get tmux running in Windows (in Ubuntu under WSL). You can then set that up as the integrated terminal in Visual Studio Code. I have this setup. If you are curious, my dotfiles for it are here https://github.com/Mellbourn/dotfiles/
I have been trying to make debugging work in this setup (WSL), but haven't quite managed it so far.
It may well have similar problems with tmux as macOS.

P.S. I've installed insiders build and will try it tomorrow on macOS

[weinand]

Yes, I'm aware of tmux under WSL or cygwin. That's why I said "native" tmux.

Currently we just don't have enough cycles to work around the tmux issue for those as well...

[Mellbourn]

I’ve run the Insiders edition now, 1.21.0 eb5e41cfd5df83b126cccf7a5483b05878ef637f.

It definitely works better now, I can get the debugger running in the integrated terminal running tmux.

However, it does feel a more flaky than before. There are two new problems:

It never works the first time I try to run the debugger (when the integrated terminal has number “1” and is called “sh”), the only thing that happens then is the classic quick flash of the debug command and that another terminal is created (“2: Node Debug Console”).
Once the “2:Node Debug Console” exists, I can successfully run the debugger.

If the integrated terminal tab is hidden when I start the debugger, then when the “2: Node Debug Console” shows up, it shows a screen filled with “.” and in the lower right corner it says “(size 206x1 from a smaller client)” as if tmux was showing a much smaller window somewhere else (on the “sh” tab?). If I switch back to the “sh” terminal tab, the problem goes away and tmux is rendered correctly again.
This problem recurs every time I hide the terminal and then show it again. Then the screen is again filled with “.” as if it was actively showing on a much smaller window. I do have aggressive-resize turned on in tmux.

Unfortunately, the last problem is fairly serious, since the point of running the debugger in the integrated terminal is that I want to watch what it is doing, so I am constantly hiding the terminal to edit the code, and then showing it again to see how my changes have affected the tests.

[Mellbourn]

After further investigation it seems to me that the problem of the tmux terminal screen filling with '.' is not directly related to the debugging problem.
Whenever a second terminal is created in the insiders build, and visibility of the terminal is toggled, this problem happens. It doesn't matter if the terminal is running a debugger or not.

This problem is specific to insiders build and does not occur in the 1.20 release version.

The problem is very noticeable when debugging, though, since the debugger creates a new terminal window.

[weinand]

thanks for your investigation. I suggest that you file another bug against the integrated terminal.

[Mellbourn]

Ok, will do.
The first issue issue i mention above still seems to be debug related, i.e. the debugger never starts the first time, only on the second try, when a second terminal has been created.

[octref]

I'll verify this. Although it does not work optimally (I can verify both #44325 and #45025), at least now #45025 allows you to use terminal/tmux to debug, albeit with some inconvenience.

44325 will likely get addressed for the upcoming 1.21 release and #45025 the next release.