Enhance colorized build output with rich mode and terminal integration#4990
Open
hanniavalera wants to merge 9 commits into
Open
Enhance colorized build output with rich mode and terminal integration#4990hanniavalera wants to merge 9 commits into
hanniavalera wants to merge 9 commits into
Conversation
hanniavalera
force-pushed
the
dev/hanniavalera/colorizedBuildOutput
branch
from
June 24, 2026 15:52
00386ef to
dd601cd
Compare
… output Adds an opt-in cmake.colorizedBuildOutput setting (off/severity, default off, window scope) that highlights build errors, warnings, and notes by severity in the CMake/Build Output panel using basic, theme-aware ANSI colors (rendered by VS Code 1.88+). Colorization is applied post-parse and only on the Output-channel echo, so the diagnostics/Problems panel and the on-disk log file keep clean text. A new pure module src/colorize.ts (with backend unit tests) classifies lines and wraps them with named SGR codes (error=bold red, warning=yellow, note=cyan, success=green) that VS Code remaps to the active theme, including High Contrast. Prototype for #478.
The VS Code Output panel is a Monaco text editor and does not render ANSI escape codes (it shows them literally), so writing ANSI to the CMake/Build output channel printed raw escape codes instead of colors. Render colorized build output in a dedicated 'CMake Build' integrated terminal (xterm.js), which interprets ANSI, and revert the output channel + on-disk log file to plain text. The task-based build path (cmake.buildTask) already runs in a terminal and is now colorized in place. The opt-in cmake.colorizedBuildOutput setting (off/severity) and the parser-safe semantic colorizer (src/colorize.ts) are unchanged.
…y footer) Extends cmake.colorizedBuildOutput with a 'rich' value and adds a companion cmake.buildOutputGlyphs (unicode/ascii). In the CMake Build terminal, rich mode adds accessible severity glyphs, dims build-progress noise, prints a bold build header, and a colored, localized build-summary footer (succeeded/failed/cancelled + error/warning counts + elapsed time). Counts come from the resolved, parser-filtered diagnostics so they match the Problems panel. Colorization stays display-only (parsing runs on clean lines); off/severity behavior is unchanged. All terminal strings are localized; basic theme-remapped ANSI only (accessible, high-contrast, color-blind aware); the closed-terminal case no longer recreates a hidden terminal. Prototype for #478.
…rrors When colorized build output is enabled, the dedicated CMake Build terminal is now the single visible surface: a failed build reveals that terminal (honoring cmake.revealLog) instead of stealing focus to the Output channel, and per-line build output is no longer duplicated into the channel (it still goes to the on-disk log file, so diagnostics are preserved). Also makes diagnostic locations clickable: a pseudoterminal has no cwd, so relative paths (e.g. Ninja's ../src/x.cpp) weren't linkable; we now rewrite a relative leading diagnostic path to an absolute one (display-only, when the file exists) so VS Code's built-in terminal link detection jumps to file:line:col. off mode is byte-identical; the Problems panel and log file are unchanged. Prototype for #478.
…piler color mode Builds on the colorized build-output feature (#478) with two additions and a hardening pass: - compiler mode: a new `cmake.colorizedBuildOutput: compiler` value that forwards the compiler's and build tools' own colors instead of synthesizing them, by setting CMAKE_COLOR_DIAGNOSTICS=ON in the configure environment (bakes -fdiagnostics-color / -fcolor-diagnostics into the build rules; requires a reconfigure to take effect) and CLICOLOR_FORCE=1 in the build environment (read at invocation, no reconfigure needed). - Portable sink abstraction: colorization now produces surface-agnostic ANSI via a ColorizedBuildSink interface with a single capability gate, canRenderAnsiInOutput() (false today), and selectSink(). The integrated terminal (BuildOutputTerminal) is used today; if a future VS Code renders ANSI in the Output panel, OutputChannelBuildSink routes the same output there with no other change. - Strip-before-parse: build output is ANSI-stripped (stripAnsi) before diagnostic parsing and before going to the on-disk log, so the Problems panel and log stay clean while the terminal still receives the raw colored line. This also hardens severity/rich against a user running with forced compiler colors. Adds the `compiler` enum value across package.json/package.nls.json/config.ts/docs, wires the task-provider and driver env-injection paths, and extends the colorize backend tests (stripAnsi, compiler passthrough, selectSink).
… terminal-to-output flow The colorized "CMake Build" terminal (and the Output channel in off mode) was revealed at the start of every build and configure, including automatic and programmatic ones - so a configure-on-open, an auto-reconfigure, or a build invoked through the CMake Tools API by Copilot (via the C/C++ DevTools companion) would yank the panel away from a terminal the user was working in. Minimize interruptions: - Add `cmake.revealLogOnAutomaticTrigger` (boolean, default false, scope window). When false, automatic/programmatic operations no longer proactively reveal the build output; explicit user-initiated builds/configures keep their `cmake.revealLog` behavior, and failures always surface. - Factor the reveal policy into a pure, unit-tested decideReveal() and thread an `isAutomatic` flag through runBuild/build/ctest/preTest plus the configure path (classified by ConfigureTrigger via isAutomaticConfigureTrigger). The CMake Tools API entrypoints (build/buildWithResult/ctestWithResult) mark themselves automatic, so the proven Copilot path is covered. editCache's "Configure Now" gets an explicit user trigger so it still reveals. - The gate applies to both the colorized terminal reveal and the Output-channel reveal. Improve terminal-to-output flow: - Add a one-line pointer in the regular Output channel at colorized build start so users who watch it aren't left with a near-empty channel. - The automatic gate also removes the configure-then-terminal panel bounce on a build that needs a reconfigure. - If the user closes the CMake Build terminal mid-build, a build failure now falls back to revealing the Output channel (reveal() returns whether a surface was shown) so failures are never silently lost. Adds backend tests mirroring decideReveal and isAutomaticConfigureTrigger.
…en the build terminal promptly Two adjustments to the colorized build-output reveal work, in anticipation of the cmake.revealLogOnAutomaticTrigger PR (#4988 / #4989) merging first: Layer on #4988 instead of diverging from it: - Align logging.ts `decideReveal` and `Logger.showChannel` to the exact shape used by #4988 (`{ shouldShow, preserveFocus }`), so when that PR merges there is a single shared implementation rather than two competing ones. `revealLogDecision` remains the only colorization-specific addition: a thin wrapper that maps `decideReveal` to the `{ show, focus }` shape the colorized terminal reveal consumes. `isAutomaticConfigureTrigger`, the isAutomatic threading, the API marking, and the setting itself are unchanged and already match #4988. Updated the backend test to the aligned shape and added coverage for the revealLogDecision mapping. Open the CMake Build terminal promptly (bug fix): - Previously the colorized terminal was only created and revealed once the build actually started, which happens after the pre-build configure. With a fresh kit/preset (e.g. gcc) the first configure is slow, so the user was left looking at configuration progress with no terminal. Now the terminal is opened and revealed before the pre-build configure (showing a brief "Preparing build…"), gated on the same reveal decision so automatic/programmatic builds still stay quiet. Adds prepareForConfigure() to the build sink (terminal and the portability Output-channel sink).
…LOG entry - Telemetry: include cmake.colorizedBuildOutput (off|severity|rich|compiler) and cmake.buildOutputGlyphs (unicode|ascii) as properties on the existing per-build telemetry event so adoption of the experimental colorized build output feature can be tracked. Both are low-cardinality enums containing no user data. The build telemetry properties object is now always defined (it was undefined in presets mode); ConfigType remains kits-mode-only as before. - CHANGELOG: fold the colorized-terminal behavior (prompt open, revealLogOnAutomaticTrigger handling) into the single colorizedBuildOutput Features entry so all colorization content lives solely under Features rather than split across Features and Improvements.
…pping when off) The colorized build-output pipeline stripped ANSI from every build line before parsing, echoing to the Output channel/log, and capturing stdout/stderr - including when cmake.colorizedBuildOutput is off. In the normal case (no ANSI) that is a no-op, but if a tool emits ANSI on its own (e.g. the user forces -fdiagnostics-color=always or CLICOLOR_FORCE), off mode was no longer byte-identical to the shipped release. Strip only when colorization is enabled: `const clean = this.colorMode === 'off' ? line : stripAnsi(line)` in both the main build consumer (diagnostics/build.ts) and the build-task path (cmakeTaskProvider.ts). Off mode now passes the raw line through to the parser, the Output channel/log, and the captured stdout/stderr exactly as before the feature, preserving the feature's opt-out safety guarantee. The colorized modes (severity/rich/compiler) keep strip-before-parse, which is where it matters since compiler mode forces real compiler colors.
hanniavalera
force-pushed
the
dev/hanniavalera/colorizedBuildOutput
branch
from
June 24, 2026 21:30
dd601cd to
b098882
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This pull request introduces a new experimental feature for colorizing CMake build output, along with several related configuration options and documentation updates. The main focus is on improving the readability and accessibility of build logs by adding theme-aware colors, severity glyphs, and enhanced formatting in a dedicated terminal. The changes also provide fine-grained control over when build logs are revealed, especially during automatic or programmatic operations. Addresses #478
New colorized build output feature and related settings:
cmake.colorizedBuildOutputsetting, which enables opt-in colorized build output in a dedicated terminal. This setting supports multiple modes (off,severity,rich,compiler) to control the level and source of colorization. [1] [2] [3] [4]cmake.buildOutputGlyphssetting to choose between Unicode and ASCII glyphs for severity markers when using therichcolorization mode, improving accessibility for terminals with limited font support. [1] [2] [3]Control over build log visibility:
cmake.revealLogOnAutomaticTriggersetting to control whether build output is revealed during automatic or programmatic operations (such as configure-on-open or builds triggered by extensions). Failures are always shown regardless of this setting. [1] [2] [3]Documentation updates:
docs/cmake-settings.mdto document the new settings and their usage, including detailed descriptions of the new colorization modes and glyph options. [1] [2]API adjustments:
src/api.tsto ensure that build and test commands run with the new default behavior for revealing logs, by passing the appropriate argument to the underlying project methods.Here are some screenshots:
