Description
This is a proposal to improve VS Code's integration with the terminal output. Currently you may have noticed that the names terminals have in the dropdown may not represent the command currently being run, especially on Windows.
Problem
On Linux and macOS the behavior is to use the name of the process executable, this does update when new processes are run but unfortunately there is up to a 200ms delay in doing this as we need to poll for it.
On Windows the behavior is to always use the basename of the shell process executable (eg. powershell.exe, cmd.exe, etc.), this does not change when there is a command run or a shell change.
Due to these limitations we can't reliably tell what process/args are currently being run, and therefore cannot surface this information to integrations.
Potential Solution
A setting something like this could be introduced:
"terminal.integrated.promptMatchers": {
"bash": "(bash-\d\.\d)?$\s(.*)",
"cmd.exe": "..."
}
Then depending on the process title we have access to described in the Problem section, we can select the valid item from promptMatchers
. This could then be used on every line of output to detect when each command starts and finished.
This would enable, among other things, the ability to register link matchers under certain conexts. For example:
// Linkify \w\.\w in the output of a ls command that will open the file when clicked
// openFile have access to the current working directory from the context
term.registerLinkMatcher(/\w\.\w/, link => openFile(link), 0, /*context*/ 'ls');
Given a shell with the default configuration this would allow us to linkify common commands in a relatively
Edge Cases
- This wouldn't work for custom shells that are launched within a Windows terminal, for example if cmd.exe is configured and powershell.exe is launched from that terminal, the cmd.exe matcher would be used.
- This would only work for the certain cases when we have the cwd as part of the prompt, if the prompt doesn't contain the cwd would this just be disabled?
- What about multiple line prompts?
Questions
- Is the setting too complex, especially with the possibility of adding regex indexes?
- This functionality would rely on per-row link matchers upstream as described in Implement web links and custom link matcher registration xtermjs/xterm.js#538 (comment)
Related items
- Allow custom link matchers to be registered in terminal API #18454 ITerminalInstance support for link detection
Blocked by
- ITerminalInstance.onData should be higher level #18453 ITerminalInstance.onData should be higher level
- Implement web links and custom link matcher registration xtermjs/xterm.js#538 xterm.js: Implement web links and custom link matcher registration
Activity
Tyriar commentedon Mar 9, 2017
Related idea that would likely be more reliable on Mac/Linux xtermjs/xterm.js#576
Tyriar commentedon Mar 15, 2017
The current thinking is to inject escape sequences into the prompt for supported shells (xtermjs/xterm.js#576) and fall back to regex matching (this issue), which can be customized by the user
20 remaining items