Skip to content

Add setting of scroll back buffer size for debug console, like integrated terminal #129493

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
zeroxia opened this issue Jul 27, 2021 · 3 comments · May be fixed by #245915
Closed

Add setting of scroll back buffer size for debug console, like integrated terminal #129493

zeroxia opened this issue Jul 27, 2021 · 3 comments · May be fixed by #245915
Assignees
Labels
debug Debug viewlet, configurations, breakpoints, adapter issues feature-request Request for new features or functionality *out-of-scope Posted issue is not in scope of VS Code
Milestone

Comments

@zeroxia
Copy link

zeroxia commented Jul 27, 2021

Hi,

I'm aware of this ticket: #68100

But not sure why it's just closed. I believe this is a valid feature request, like this: Dart-Code/Dart-Code#1613

My scenario is: on Windows we use "OutputDebugStringW" to do logging, which will cause all messages to go to the debug console, and I think it's very handy to keep logs in separate window to have a clean terminal for interaction with user etc.

It seems that there were some performance issues reported on debug console scrolling, then the result is this buffer size is just hard limited to 10,000 lines, like this: #71737

So can we have a setting like terminal.integrated.scrollback to control the size of scroll back buffer for the debug console, instead of hard limiting it to 10,000 lines?

Not sure if the "filtering window" can cause performance issue with the bigger scroll back buffer, but to me it's OK to just disable this filtering window. I'd rather have the full buffer, and I can copy it all to an editor to check. But for now I can only copy 10,000 lines and all those before it are just lost.

Thanks.

@weinand weinand added the debug Debug viewlet, configurations, breakpoints, adapter issues label Jul 27, 2021
@weinand
Copy link
Contributor

weinand commented Jul 27, 2021

@zeroxia Could you try to use the "integrated terminal" instead of the "debug console"?
The debug console was designed to be a REPL, not for capturing huge logs...

@isidorn isidorn added the feature-request Request for new features or functionality label Jul 27, 2021
@isidorn isidorn added this to the Backlog milestone Jul 27, 2021
@zeroxia
Copy link
Author

zeroxia commented Jul 29, 2021

@zeroxia Could you try to use the "integrated terminal" instead of the "debug console"?
The debug console was designed to be a REPL, not for capturing huge logs...

In Visual Studio, the output window can hold a lot of these logs from OutputDebugStringW function call, and terminal is another window that can take contents from std::cout or std::cerr, I personally like this setup. In Xcode, the termnal is re-used as terminal and REPL, which is very messy when there is a lot of logs dumped.

Actually Visual Studio has both "Output" window and "Immediate" window. Maybe VS Code can follow this?
This is what I expect to be more fluent work flow for C/C++:

  1. Developer hits F5 to start debugging
  2. The cmake-tools starts building the project, "Output" window is activated, and switched to "CMake/Build" buffer
  3. If build failed, all is stopped, developer can inspect the "Output" window for building issues.
  4. If build succeeded, program is launched, "Output" window is switched to a new buffer, e.g. called "Log (Debug)", which will have all those logging messages from OutputDebugStringW.

This is how Visual Studio behaves, and I personally think it's convenient and reasonable.

Furthermore, when the program is launched, it would be ideal for developer to configure whether to focus to the integrated terminal automatically or just keep at the output window for the "Logging".

Again, in this setup, the "Output" window should allow user to configure a large scrollback size to hold all logs if the program is long running or very verbose...

Thanks!

@isidorn isidorn added the *out-of-scope Posted issue is not in scope of VS Code label Aug 13, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
debug Debug viewlet, configurations, breakpoints, adapter issues feature-request Request for new features or functionality *out-of-scope Posted issue is not in scope of VS Code
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants
@zeroxia @weinand @isidorn and others