Change:
<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --So far, I haven't been able to find any issues around this, but I also haven't found a ton of documentation on this feature either. Basically, I'd like to have finer grained control over how the terminal "word link" auto detection works. This is one of the only comments I was able to find about: Example: In the terminal, I have some output from a compiler that includes relative paths that can be clicked conveniently as an autodetected "word link": Specifically, clicking takes me to the line in question, which is great! However, at some point I tried configuring to include a forward slash (colon has related effects too), e.g. By doing so, the auto-detected file path is no longer clickable, since each path segment is considered as a separate word instead. Notably, the absolute path above is still clickable, but relative paths appear not to be (unless I remove from again). I guess there is probably more than one way to solve this, but a simple solution that comes to mind would be to have a separate config, maybe something like . If null it could fall back to the value, but at least this way it would be possible to configure different separators for double-click selection and link detection. Thanks in advance!
This case is meant to work with the regular non-word link detection as you can see here: <img width="490" alt="Screenshot 2023-05-08 at 6 31 15 am" src="https://user-"This may not work is if the relative path is not relative to the current working directory or you have shell integration disabled (which is provides better cwd detection). In your example is relative to the directory the terminal was currently on? The word links are meant to catch the majority of cases where the verified file links fall through.
Edit: never mind, I think I was testing with the wrong value of as I described in the original issue body :( I did however notice an interesting data point while integration was still disabled: the clickability of the file path seemed inconsistent. Here are a few screenshots showing what I mean (ctrl held in each case): Can't click in a compiler diagnostic, maybe due to the prefix on that line? ! A command I wrote without line/column numbers works fine: ! A command I wrote with line/column numbers works fine: !
It's a little hard to tell if this is by design or not without knowing the exact cwd and full path of these folders. What we're going for is verify if the file is real if it's relative to the current working directory (which is citro3d-rs in your last 2, not sure for the first), otherwise fall back to word links. Since you changed wordSeparators, the fall back isn't as useful, but it looks like it's working properly.
Ah sorry I forgot to include those extra details. The cwd and path was the same in all 3 cases (i.e., the relative file path should work in each case, I think?): I guess the part that doesn't make sense to me is why the latter two cases work but the first one doesn't - since in each case the path is the same and I haven't changed directories at all. I suppose the workaround of removing and from is still an option but it would be nice if the linking was more consistent.
Yeah this is strange if it's all the same cwd. I Can't repro here I'm improving trace logging in , when that is released to insiders (the day after it's merged) you will be able to set the log level via the command palette (F1) and view the trace logs when hovering the terminal line by looking in the Output panel Window dropdown entry. That will give us some more info on why this is happening.
The logging changes should be in tomorrow's insiders
thanks for that, here is the trace log output that I think is relevant for debugging. Please let me know if you need more info or another reproduction: Edit: the cwd again was and the relative path should resolve: <details<summarytrace output</summary</detailsOne odd thing I noticed - without changing any settings, I actually had one instance where it worked as expected and linked the relative path to . However I'm not sure how or why it worked. When I opened a new terminal the old behavior (not linking) came back. If I can reproduce that again I'll try to capture those trace logs and maybe it will highlight a difference in behavior that's helpful. Thanks again for looking at this!
So there's this in the logs: So it's parsed as a possible link, but not made a link candidate (which checked the file system before making the link). Somehow this part isn't adding the candidate: The only way I think that could happen is if doesn't return anything. I another log to verify the cwd and also improved fallback in case it is undefined. Can you do the same again on the next Insiders which should come out on Monday?
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!
sorry for the delay, was a bit busy last week but I was able to check with a recent build (): The link is clickable now, even with and both in ! I'm guessing the fallback changes you did the trick. It seems the triage bot closed this as "not planned" but maybe you are able to update its status to "fixed" or similar? Thanks for your help looking into this issue!
great news! I still don't totally understand how it was failing before but at least the issue is fixed

Discussion:
import { IBufferLine, IBufferRange, Terminal } from 'xterm'; import { ITerminalBackend, ITerminalProcessManager } from 'vs/workbench/contrib/terminal/common/terminal'; import { detectLinks } from 'vs/workbench/contrib/terminalContrib/links/browser/terminalLinkParsing'; <ins> import { ILogService } from 'vs/platform/log/common/log'; </ins> const enum Constants { /**

private readonly _capabilities: ITerminalCapabilityStore, private readonly _processManager: Pick<ITerminalProcessManager, 'initialCwd' | 'os' | 'remoteAuthority' | 'userHome'> & { backend?: Pick<ITerminalBackend, 'getWslPath'> }, private readonly _linkResolver: ITerminalLinkResolver, <ins> @ILogService private readonly _logService: ILogService, </ins> @IUriIdentityService private readonly _uriIdentityService: IUriIdentityService, @IWorkspaceContextService private readonly _workspaceContextService: IWorkspaceContextService ) {

const os = this._processManager.os || OS; const parsedLinks = detectLinks(text, os); <ins> this._logService.trace('terminalLocaLinkDetector#detect text', text); this._logService.trace('terminalLocaLinkDetector#detect parsedLinks', parsedLinks); </ins> for (const parsedLink of parsedLinks) { // Don't try resolve any links of excessive length if (parsedLink.path.text.length > Constants.MaxResolvedLinkLength) { continue;

} } linkCandidates.push(...specialEndLinkCandidates); <ins> this._logService.trace('terminalLocaLinkDetector#detect linkCandidates', linkCandidates); </ins> // Validate the path and convert to the outgoing type const simpleLink = await this._validateAndGetLink(undefined, bufferRange, linkCandidates, trimRangeMap);

parsedLink.prefix?.index ?? parsedLink.path.index, parsedLink.suffix ? parsedLink.suffix.suffix.index + parsedLink.suffix.suffix.text.length : parsedLink.path.index + parsedLink.path.text.length ); <ins> this._logService.trace('terminalLocaLinkDetector#detect verified link', simpleLink); </ins> links.push(simpleLink); }

import { IFileService } from 'vs/platform/files/common/files'; import { createFileStat } from 'vs/workbench/test/common/workbenchTestServices'; import { URI } from 'vs/base/common/uri'; <ins> import { ILogService, NullLogService } from 'vs/platform/log/common/log'; </ins> const unixLinks: (string | { link: string; resource: URI })[] = [ // Absolute

return createFileStat(resource); } }); <ins> instantiationService.stub(ILogService, new NullLogService()); </ins> resolver = instantiationService.createInstance(TerminalLinkResolver); validResources = [];