Also corrects the showDirectory entry, which is an enum now, and states
plainly that drag-to-dock is impossible in a webview view.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A fair question about the custom list: what does it buy over the built-in
Open Editors view? Most of the answer was the project colours — and those do
not need a custom view. A FileDecorationProvider puts them on the built-in
Open Editors view, the Explorer and the tabs, which keeps everything native
that view already does, including the drag-to-dock this list cannot offer.
verticalTabs.decorateFiles is off / color / colorAndBadge, defaulting to
color. Badges are the two characters a FileDecoration allows, taken from the
first and last segments of the project name so that Acme.Shop.Client and
Acme.Shop.Server read as AC and AS rather than colliding.
Two limits are documented rather than papered over: there is no way to
decorate only the Open Editors view, so the Explorer is coloured too; and Git
decorates modified files with only one colour winning, so a dirty file can
show Git's colour instead of its project's.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The colour is a left border now, not a tinted icon; pinning is one toggle;
row spacing and border width are settings; and file-type icons are gone,
which is worth stating plainly along with the reason.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
For working with the tab bar off, where a side list is the tab bar. VS Code's
Open Editors view already does pinning; what it does not do is colour by
project, and it is a tree rather than a flat list.
- A Tabs view in the Explorer: one row per open editor, no group nodes. A
TreeDataProvider whose items have no children renders as a list, since
there is no separate list API.
- Each row's icon is tinted by the project containing the file — the nearest
.csproj/.fsproj/.vbproj, package.json, Cargo.toml, go.mod, pyproject.toml,
pom.xml or build.gradle above it, configurable. The colour comes from a
hash of the project name, so a project keeps its colour across sessions
rather than depending on the order tabs happened to open in. Eight
contributed theme colours, all overridable.
- Sort by open order, project (so the colours run in blocks), or file name,
with pinned tabs lifted to the top.
- Close, close others (keeping pinned), pin/unpin, copy path, reveal.
- The list follows the active editor.
Two API limits shape this, both covered by tests:
- Nothing can activate an arbitrary tab. A file-backed tab is focused by
re-opening its resource in its own group, which handles text, diffs,
notebooks and custom editors. Webview tabs have no resource, so they are
listed and marked as unfocusable instead of pretending.
- Only the *active* editor can be pinned, so pinning another row focuses it
first.
Commands act on live vscode.Tab objects rather than the row snapshots handed
to them. The first cut compared against a snapshot's isPinned and so silently
did nothing on unpin, and read the provider's cached list, which is empty
until the tree has been rendered.
Also worth recording, both found by the tests: VS Code moves a pinned tab to
the front of its group, so `open` order shows pinned first regardless of the
pinnedFirst setting; and closeAllEditors leaves pinned editors open, so test
cleanup closes through the tab API instead.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
maxandClaude Fable 5.1