Mark write references in the editor view too
Kinds now live on the display ranges rather than in a side map, so the virtual document can paint reads and writes differently. - ResultLine.symbolRanges becomes DisplayRange[] carrying start, end, the source column and the kind. displayLine() classifies syntactically as it renders, so the write markers are correct on the very first paint and the document never waits on a language server. refineKinds() then applies documentHighlight results and re-decorates; only decorations change, never the text, and a superseded tab is left alone. - Writes get the theme's editor.wordHighlightStrong colours plus bold, which is what the editor itself uses for a write occurrence, so the two kinds are distinguishable in any theme. Reads keep the find-match highlight. - DisplayRange.sourceCol replaces the arithmetic that recovered a source column by shifting relative to the first reference on the line. Covered by a new test that walks every occurrence on a line holding two references to the same symbol and checks each one navigates to its own column. Also drops a stale assertion: an empty kind map used to mean "everything reads", and now means "use the syntactic classification", so buildRows() without a map is expected to report writes. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
@@ -4,8 +4,9 @@ Find All References results shown the way Visual Studio does it — in two views
|
||||
|
||||
**Editor view** (default) writes the results into a read-only virtual document in the *same language as your
|
||||
source file*, so your theme's grammar colors every line for free. File headers show the containing project
|
||||
(`.csproj`/`.fsproj`/`.vbproj`) and reference count; the referenced symbol is highlighted; line numbers are
|
||||
shown in the gutter.
|
||||
(`.csproj`/`.fsproj`/`.vbproj`) and reference count; line numbers are shown in the gutter. Read references are
|
||||
highlighted like search matches; **writes are bold** on the theme's stronger write-occurrence background, the
|
||||
same colour the editor itself uses for a write.
|
||||
|
||||
**Panel view** shows the same results as a table with resizable, sortable columns — Code, File, Line, Kind,
|
||||
Project and Containing member — grouped by file, with a filter box and a reads/writes filter. By default it
|
||||
@@ -76,7 +77,8 @@ the expected results stay deterministic.
|
||||
arguments), then `textDocument/documentHighlight` is asked per file and its `Read`/`Write` kinds override
|
||||
that wherever the server has an opinion. Servers that answer with plain `Text` highlights, or not at all,
|
||||
leave the syntactic answer standing — which is good for straightforward code and can be wrong for exotic
|
||||
expressions. Results spanning more than 60 files skip the server round-trip entirely.
|
||||
expressions. Results spanning more than 60 files skip the server round-trip entirely. The editor view paints
|
||||
the syntactic answer immediately and re-paints if the server disagrees, so it never waits on highlights.
|
||||
- Some language servers try to attach to every document of their language, including the virtual one, and may
|
||||
log a harmless error about an unknown URI scheme.
|
||||
|
||||
@@ -86,4 +88,4 @@ the expected results stay deterministic.
|
||||
result sets, and remembering column layout per workspace rather than per panel
|
||||
2. Semantic token overlay via `vscode.provideDocumentSemanticTokens`
|
||||
3. Filter by project / exclude tests
|
||||
4. ~~Read/write kind~~ — done for the panel; the editor view does not mark writes yet
|
||||
4. ~~Read/write kind~~ — done in both views
|
||||
|
||||
Reference in New Issue
Block a user