Feature request: focus on gdb terminal output while programming and on debug console when finished

[RolfNoot]

We are supplying a pack with setup and extensions to our customers and we spend a lot of time to direct our users to the terminal output / debug console.

It would GREATLY improve user experience if the focus is on the window where the actual process is running.

I envision two options for user experience enhancement:

• forward all terminal output to the debug window and give it focus (preferred)
• shift focus between terminal output and debugging console.

Optionally what would even more improve experience is a colored output where lines containing 'error' and 'warning' are colored / highlighted differently. We used to use this extension for that but since the output changed to the terminal console, we cannot use it anymore.

Thanks! Rolf

[RolfNoot]

Any news on this?

[haneefdm]

Q? What is a gdb terminal? You mean Debug Console? This is where the output of the debugger goes - whether it is gdb or something else

This window is managed by VSCode. We would rather not mess with it or how its focus works. VSCode changes focus to the Debug Console in very specific instances - when a program is paused or breakpoint is hit is one example. It also does not mess with the focus that much as that causes shimmering. Remember, that real estate is used by many VSCode clients/purposes. Again, we don't want to mess with the design of VSCode. Please talk to them.

The only mechanism we use to tell VSCode about what is going on is using their API (Debug Protocol)

https://microsoft.github.io/debug-adapter-protocol/specification#Events_Output

Note that the actual debugger is NOT a GUI program. VSCode is the GUI here that handles these messages for coloring.

Also, we don't interpret the output of gdb -- or the program being debugged -- other than if gdb indicates the type of output (log, console, error, etc) -- which gets translated to the appropriate VSCode API

The debug console has so many message sources all going into one area. From the top of my head,

• gdb server
• this debugger's backend (the non-gui part)
• this debuggers debug messages
• gdb
• gdb's debuggee

This is why we don't want to interpret these messages, and for a window that we don't own/control

I also think you are confusing the term 'terminal' Are you using VSCode terminology? Or Unix/Linux?

[RolfNoot]

When launching the debugger, the shell output gdb-server will go to the 'TERMINAL' window of VS Code. I believe was changed in the past when the output went to 'OUTPUTS' > 'Cortex Debug (extension host)'.

When the gdb server is busy (eg. programming), the process should be visible for the user IMHO. Also when the gdb-server fails to connect, focus should not go to the 'CONSOLE' window (where it now only informs the user: 'OpenOCD: GDB Server Quit Unexpectedly. See gdb-server output in TERMINAL tab for more details.')

[haneefdm]

Again, issues with terminology. There is no "shell output gdb-server". It is simply the gdb-server's stdin/stdout/stderr, also called stdio. Nothing to do with any "shell".

Yes, a couple of years ago, for gdb-server stdio, we changed from using the OUTPUT tab to the TERMINAL tab, The OUTPUT tab as defined by VSCode, is strictly output. But gdb-servers were supposed to be bidirectional (input and output) and we got many requests for full functionality. So, we had to move it to the TERMINAL tab. For semihosting, some gdb-servers (JLink, STLink, OpenOCD, etc.) require this to be bi-directional. See section 3.2 here

https://community.st.com/t5/stm32-mcus/how-to-use-semihosting-with-stm32cubeide-and-stm32/ta-p/49742

You would have known much of the above if you had read our changelog and browsed through our issues.

https://github.com/Marus/cortex-debug/blob/master/CHANGELOG.md#v040

Before you argue, I do think semihosting is beyond silly, but some people use it. BTW, our TERMINAL's do support ANSI encoding for coloring as is shown in SEGGER RTT code examples.

The stdout of the gdb-server is also directed to the Debug Console where you CAN see the programming messages. Almost all gdb-servers use this mechanism for interesting information that users should see. Rest is chatter. I may have stdout/stderr backwards but that is the convention used and what we follow.

Programming is NOT a distinct phase for us. It is just an optional part of a startup sequence.

Not re-opening this issue.

[RolfNoot]

I am sorry, I never meant to cause any confusion. I though I was clear on the TERMINAL tab but maybe I had a beer before typing the issue.

Of course I've seen the changelog back then but that doesn't relate to my question of having 'all terminal output' forwarding to the DEBUG CONSOLE or changing focus to the TERMINAL tab.

I've read your personal note and I am very sorry to bother you. I hope I will figure out myself how I can get the full output which currently goes to the TERMINAL tab forwarded to the DEBUG CONSOLE tab.

Wishing you a good recovery and thank you for the wonderful work you did on this extension!

[RolfNoot]

Final question, are you using "overrideLaunchCommands"? If yes, I get the programming messages. If not, I might be missing something but I don't get programming messages in the DEBUG CONSOLE tab!

Thank you for any guidance.

[haneefdm]

You should submit a proper issue with all the details using our Issue template.

AFAIK, we don't do anything special for overrideLaunchCommands -- if you don't supply one, we provide one based on the server type.

The logic that interacts with the server process and studio does not know what commands are being sent to gdb, or by whom, or why. But there may be some weird interaction that I cannot imagine because all the details are missing. You can show me/others with or without overrideLaunchCommands what you are seeing and what is in overrideLaunchCommands. This is how others can help as well.