Change:
if (result) { const { uri, isDirectory } = result; const linkToOpen = { <del> text: matchLink, </del> <ins> // Use the absolute URI's path here so the optional line/col get detected text: result.uri.fsPath + (matchLink.match(/:d+(:d+)?$/)?.[0] || ''), </ins> uri, bufferRange: link.bufferRange, type: link.type

Discussion:
Issue Type: <bBug</bregression: i use this all the time, and this got broken again with the latest update. VS Code version: Code 1.65.1 (, 2022-03-08T02:06:27.846Z) OS version: WindowsNT x64 10.0. Restricted Mode: No Remote OS version: Linux x64 5.10.60.1-microsoft-standard-WSL2 Remote OS version: Linux x64 5.10.60.1-microsoft-standard-WSL2 <details<summarySystem Info</summary </details<details<summaryExtensions (8)</summaryExtensionVersion ------ gitkraken-authentication1.0.3 remote-ssh0.76.1 remote-ssh-edit0.76.1 remote-wsl0.64.2 gitlens12.0.2 autoscrolldown1.2.1 gitkraken-authentication1.0.3 cpptools1.8.4 </details<!-- generated by issue reporter --
ok, it looks like it's a little more subtle than that issue. sometimes ctrl-clicking a link in the terminal window shows the pre-populated search-by-files popup, and then navigates to the correct location. other times it just opens the file directly and puts the cursor at the stsart of line regardless of the value in the terminal link. it looks like the terminal link parser is actually highlighting the correct part of the link (up-to and not including the trailing ':')
it also seems like there's some kind of background processing going on. sometimes the links in the terminal don't update immediately and sometimes hovering on a newly typed line shows the link in the location as if that line had not been typed (ie in the location of where the previous line was before it scrolled up).
here's a demo: first i click a link to , it opens the popup as usual, and then correctly navigates to line 5. then i click a link to . this time it immediately opens the file (no popup) and fails to navigate to the correct line. note that the clicked link in the terminal does underline the part. i'm not sure what determines whether or not it does this. it's not dependent on either file size, location or extension, as far as i can tell. This also repos with extensions disabled.

I have verified that typing into the search-by-files dropdown does_ navigate correctly to the given line.
I can reproduce this in stable and it appears to be fixed already in Insiders, could you verify your problems is fixed in
no. this is NOT fixed in 1.66.0-insider. please reopen. same behavior as before. seemingly randomly, clicking on links to some files opens the popup and navigates to the given line number, other files just jump to the first line of the file without opening the popup.
thanks for the follow up Can reproduce, here are more specific steps: shell integration is disabled a file in the root folder that will not match any other file in the workspace , it will open to line 1
i can confirm that the problem seems to go away if i enable shell integration.
Not yet fixed according to
The supposed fix has broken other link detection. VS Code no longer picks up Only the file name is highlighted.
I don't think the part was ever supported but line works for me: ! This works with and without shell integration enabled. Did you create the terminal in the parent folder of ?
In previous versions of code, the entire thing was highlighted. Notably before was required to click on links. Yes.
the patterns are defined here: The file did move I think 6-12 months ago, but searching recent git history for "characters" comes up with zero results. I don't believe we ever removed patterns here, that would also result in tests failing. Also ctrl was always required to click links if I'm remembering right (maybe not very early on several years ago?). Can you create a new issue with repro steps? It's a different problem then what's tracked here.
The characters part wasn't highlighted, I was mistaken about that. If you want to see what it looks like have a look at I can open a new bug report also.
is supported as shown above from this line: however isn't, it was a feature request here but got closed off as it didn't get enough votes. Is this confusion around both and not being supported but being supported?
Found my way here because V1.71.2 doesn't seem to immediately accept Jest references like "". It WILL jump to the right place, but only after popping the 'partial match' file selector, showing 2 other partial match cases in my scenario.

It's a perfect match to a local file - I expect it should just jump straight to the line, right? Am I expecting too much?
I fixed the trailing colon problem yesterday in which will land in insiders in a few days (after 1.74.0 stable goes out). This is specifically about the issue in the top comment which points at The fix specifically targeted , this is the type of link above as it's missing the path indicators (eg. , , etc.). There are other types of links which I also believe are fine but please open an issue with a specific repro if you find an edge case that isn't working.
just to make sure I test the right thing, can you give steps?
A word link (those that need ctrl/cmd held) should include the :line:col. Just verified it myself: ! <img width="99" alt="image" src="https://user-"