You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Log import progress to a LogOutputChannel not a Terminal #4168
It's surprising that we use a terminal to log project import progress instead of using an output channel. It would be better if we could log such things to an output Channel.
Not sure output channels are a good fit here. Using a terminal allows for each active process to be updated on a single line.
It's easier to visually parse, rather than scroll through 100s of lines. Now maybe that argument is moot if you can rewrite existing lines in Outputs, I don't know.
It just seems very weird. Seems like we're trying to bring the Eclipse concept of Progress reporting to VS Code, but VS Code does not have that concept. If we're trying to recreate the progress view from Eclipse, why not just make a view?
I mean, technically we do. They're all available as $/progress notifications in the standard language server output view. Just that they're very difficult to read. Presenting the user with progress in different formats, depending on what VS Code supports is basically what this is doing. The log is the raw paper trail, and this is a bit more compact. The progress report, even more so.
I found java.showBuildStatusOnStart.enabled which defaults to notification. The build status can still be brought up with a command, or by clicking for more details on the progress notification.
I'm not really hung up on this one. It's just that we're using a UI concept which does not really exist in VS Code ("Progress view"). Progress in VS Code is ephemeral and is not designed to convey important, persistent information. I just wonder why having this information (instead of just going with the VS Code progress) important enough to warrant the unexpected UI.
Activity
fbricon commentedon Sep 22, 2025
Not sure output channels are a good fit here. Using a terminal allows for each active process to be updated on a single line.
It's easier to visually parse, rather than scroll through 100s of lines. Now maybe that argument is moot if you can rewrite existing lines in Outputs, I don't know.
tsmaeder commentedon Sep 22, 2025
It just seems very weird. Seems like we're trying to bring the Eclipse concept of Progress reporting to VS Code, but VS Code does not have that concept. If we're trying to recreate the progress view from Eclipse, why not just make a view?
rgrunber commentedon Sep 26, 2025
I mean, technically we do. They're all available as
$/progressnotifications in the standard language server output view. Just that they're very difficult to read. Presenting the user with progress in different formats, depending on what VS Code supports is basically what this is doing. The log is the raw paper trail, and this is a bit more compact. The progress report, even more so.I found
java.showBuildStatusOnStart.enabledwhich defaults tonotification. The build status can still be brought up with a command, or by clicking for more details on the progress notification.tsmaeder commentedon Sep 26, 2025
I'm not really hung up on this one. It's just that we're using a UI concept which does not really exist in VS Code ("Progress view"). Progress in VS Code is ephemeral and is not designed to convey important, persistent information. I just wonder why having this information (instead of just going with the VS Code progress) important enough to warrant the unexpected UI.
fbricon commentedon Sep 26, 2025
vscode progress doesn't scale when you have tens of parallel processes, a dedicated "view" fits better