Bug
findLinksInText (in rangelink-core-ts, called by RangeLinkDocumentProvider.provideDocumentLinks) marks a string like (packages/foo.ts#L42-L45 as a clickable RangeLink, including the leading ( in the matched range. When the user clicks the link, navigation fails with Cannot find file: (packages/....
Existing tests in packages/rangelink-vscode-extension/src/integration-tests/suite/linkGeneration.test.ts cover backtick, single-quote, double-quote, angle-bracket, and Markdown [text](path) wrapping. They do not cover bare parens-in-prose ((path#Lx-Ly)), which is the case that fails here.
Reproduction
In any text buffer (note, markdown, source comment, …) include a RangeLink-style reference inside parentheses followed by a sentence terminator. Example:
... the self-paste-blocked branch (packages/rangelink-vscode-extension/src/feedback/OperationFeedbackProvider.ts#L154-L162): ...
The text is detected as a clickable link (the "Open with RangeLink" tooltip appears). Clicking the link shows the toast Cannot find file: (packages/.... The parsed path and quotedPath both retain the leading (.
Root cause
The detector's matched-range computation includes the opening ( in the link's start range, so VS Code passes the dirty string (packages/... to the navigation handler. Once the leading bracket is in the path, no workspace resolution can succeed.
Proposed fix
Adjust findLinksInText so that surrounding bracket characters, quotes, and trailing sentence terminators are excluded from the matched range:
- Brackets/quotes (symmetric):
(), [], {}, <>, '', "", ``.
- Trailing sentence terminators:
., ,, :, ;.
The fix lives at detection time. The navigation handler receives a clean path, the tooltip range is visibly correct (paren not underlined), and any future consumer of the parsed link object sees a clean path and quotedPath without per-consumer defensive trimming.
Both leading AND trailing surrounding punctuation are trimmed in one pass — symmetric cases (trailing . or , after a bare link mid-sentence) follow the same rule.
Regression tests
Two unit-level cases for the detector:
- Minimal synthetic case:
(foo.ts#L1-L2) parses to path = foo.ts with the matched range containing exactly foo.ts#L1-L2 (no surrounding parens).
- Prose-embedded case: a RangeLink inside parentheses followed by
: — e.g. ... branch (foo.ts#L154-L162): ... — parses with the matched range excluding both the leading ( and the trailing ):.
Add these alongside the existing wrapped-link-navigation-* tests in packages/rangelink-vscode-extension/src/integration-tests/suite/linkGeneration.test.ts and at the unit level in the rangelink-core-ts package.
Bug
findLinksInText(inrangelink-core-ts, called byRangeLinkDocumentProvider.provideDocumentLinks) marks a string like(packages/foo.ts#L42-L45as a clickable RangeLink, including the leading(in the matched range. When the user clicks the link, navigation fails withCannot find file: (packages/....Existing tests in packages/rangelink-vscode-extension/src/integration-tests/suite/linkGeneration.test.ts cover backtick, single-quote, double-quote, angle-bracket, and Markdown
[text](path)wrapping. They do not cover bare parens-in-prose ((path#Lx-Ly)), which is the case that fails here.Reproduction
In any text buffer (note, markdown, source comment, …) include a RangeLink-style reference inside parentheses followed by a sentence terminator. Example:
The text is detected as a clickable link (the "Open with RangeLink" tooltip appears). Clicking the link shows the toast
Cannot find file: (packages/.... The parsedpathandquotedPathboth retain the leading(.Root cause
The detector's matched-range computation includes the opening
(in the link's start range, so VS Code passes the dirty string(packages/...to the navigation handler. Once the leading bracket is in the path, no workspace resolution can succeed.Proposed fix
Adjust
findLinksInTextso that surrounding bracket characters, quotes, and trailing sentence terminators are excluded from the matched range:(),[],{},<>,'',"",``..,,,:,;.The fix lives at detection time. The navigation handler receives a clean path, the tooltip range is visibly correct (paren not underlined), and any future consumer of the parsed link object sees a clean
pathandquotedPathwithout per-consumer defensive trimming.Both leading AND trailing surrounding punctuation are trimmed in one pass — symmetric cases (trailing
.or,after a bare link mid-sentence) follow the same rule.Regression tests
Two unit-level cases for the detector:
(foo.ts#L1-L2)parses topath = foo.tswith the matched range containing exactlyfoo.ts#L1-L2(no surrounding parens).:— e.g.... branch (foo.ts#L154-L162): ...— parses with the matched range excluding both the leading(and the trailing):.Add these alongside the existing
wrapped-link-navigation-*tests in packages/rangelink-vscode-extension/src/integration-tests/suite/linkGeneration.test.ts and at the unit level in therangelink-core-tspackage.