Add pinned/favorite CMake cache variables to Project Status panel

[Copilot]

This change addresses item #3463

This changes visible behavior

Users with parametric projects (e.g., firmware parameterized by HARDWARE_ID and PRODUCT_ID) can now pin frequently changed CMake cache variables directly in the Project Status sidebar for inline editing, instead of opening the full Cache Editor UI or relying on build tasks/terminal.

The following changes are proposed:

• Add PinnedCacheVariablesNode / PinnedCacheVariableNode to the cmake.projectStatus tree view, rendered between Configure and Build nodes when variables are pinned
• Three new commands: cmake.projectStatus.pinCacheVariable (quick-pick from cache), editPinnedCacheVariable (input box → updates cmake.configureSettings, respects configureOnEdit), unpinCacheVariable
• Pin button in the view title bar; inline edit $(edit) and unpin $(close) buttons per variable
• Pinned variable names persisted in workspaceState (project-local, not committed to source); values read live from the CMake cache on each refresh
• Pass extensionContext from ExtensionManager → ProjectStatus → TreeDataProvider for workspace state access
• Multi-root workspace aware: configuration scope uses the active project's workspaceFolder

Other Notes/Information

• No new dependencies. No new settings in settings.json — storage is workspace state only.
• The pinned section only appears when ≥1 variable is pinned (no visual clutter by default).
• Filtering excludes INTERNAL and STATIC cache entry types from the pin quick-pick, matching the existing Cache Editor UI behavior.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Add "favorites" functionality for frequently changed cmake cache variables</issue_title>
<issue_description>### Brief Issue Summary

My workplace project is parametrized by two cache variables:

• the hardware identifier for which the firmware is built on
• the product identifier which controls enabled set of functionality

Having cmake variant for each identifier pair gets quickly out of hand, so having the dropdowns for both values on cmake sidebar, somewhere near project outline, is desired.

I could just go to cmake cache ui each time, but currently calling build tasks which set one of the vars or typing that in integrated terminal is faster, although the build task list also gets bigger and bigger, and terminal approach is not that discoverable for my workplace colleagues.

CMake Tools Diagnostics

No response

Debug Log

No response

Additional Information

No response</issue_description>

<agent_instructions>## Feature: Pinned / Favorite CMake Cache Variables in the Project Status Panel

Context

In microsoft/vscode-cmake-tools, the CMake Project Status sidebar panel (cmake.projectStatus tree view) already exposes key build settings as inline-editable tree items: kit, variant, configure preset, build preset, build target, test preset, launch target, etc.

Users with parametric projects (e.g., firmware with HARDWARE_ID and PRODUCT_ID cache variables) currently have no fast, discoverable way to change a small number of frequently-tweaked CMake cache variables short of opening the full Cache Editor UI (cmake.editCacheUI), adding proliferating build tasks, or typing in the terminal. This is mentioned in #3463 - #3463

Goal

Add support for pinned/favorite CMake cache variables surfaced as inline-editable items directly inside the existing cmake.projectStatus tree view — not as a new standalone tree view — to minimize sidebar real estate impact. Make sure that there is no visual clutter.

The experience should feel like the existing kit/preset rows: a label showing the variable name + current value, with an inline $(edit) action that opens a quick-pick or input box to change the value (and re-triggers configure if cmake.configureOnEdit is true).

What to explore and implement - this is merely a suggestion, take it somewhat with a grain of salt

1. Storage: Where should the list of pinned variable names be persisted?

   • Consider VS Code workspace state (context.workspaceState) so it's project-local and not committed to source.
   • Alternatively, a new cmake.pinnedCacheVariables setting (array of strings) in settings.json.
   • Evaluate tradeoffs (discoverability vs. portability).

2. Data model: After configure, the extension already reads the CMake cache (see cmakeProject.ts / codeModel). Pinned variable items should read their current value live from the cache model, not store the value themselves.

3. Tree view integration: Add a new viewItem context key (e.g., 'pinnedCacheVar') to the existing cmake.projectStatus TreeDataProvider. Items should appear in a logical location — after the configure preset row and before the build preset row is a reasonable default. They should:

   • Show label: VAR_NAME: current_value
   • Support inline $(edit) button → triggers cmake.projectStatus.setPinnedCacheVariable command
   • Support inline $(remove) button → removes the variable from the pinned list

4. Commands to implement:

   • cmake.pinnedCacheVariables.pin — show a quick-pick of all known cache variables (from the cache model) and add the selected one to the pinned list
   • cmake.projectStatus.setPinnedCacheVariable — triggered from the inline edit button; show input box pre-filled with current value; on confirm, call cmake -D VAR=VALUE or update cmake.configureSettings and re-configure
   • cmake.pinnedCacheVariables.unpin — remove a variable from the pinned list (also accessible via inline remove button)

5. UX constraints:

   • No new top-level tree view — integrate into cmake.projectStatus only.
   • Keep the number of pinned variables user-controlled (no auto-detection).
   • Show a friendly placeholder row ("Pin a cache variable…" with $(add) icon) when the list is empty, wired to cmake.pinnedCacheVariables.pin.
   • The "Pin a cache variable" command should also appear in the cmake.projectStatus view title action bar (next to the existing settings/refresh icons).

6. Configure-on-change: After the user sets a new value, the extension should apply it consistently with how cmake.configureSettings overrides work, and respect cmake.configureOnEdit.

Files likely to touch

• src/cmakeProject.ts — cache variable reading
• src/ui/projectStatus.ts (or equivalent tree provider) — add new tree items
• package.json — new c...

• Fixes Add "favorites" functionality for frequently changed cmake cache variables #3463

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.