Shell integration: Explore how we're going to run the shell scripts

[Tyriar]

Parent issue #133084

Shell integration works by running a script in the shell which allows us to extract insights about what's going on in the shell. How do we run this exactly?

• Activated via CLI? eg. --rcfile, args in built-in profile like pwsh (integrated)?
• Activated via environment variables?
• Install manually in rc file?

The mechanism may differ across shells. We should consider how the user discovers the feature and how easy it is to setup.

[Tyriar]

@andschwa FYI we're doing "shell integration" this version, it occurs to me though there will be a bit of a weird state if we add a built-in profile called "PowerShell (Integrated)", next to "PowerShell Integrated Console". Did you have any thoughts on this? You can read about what shell integration will bring in #133084

[andyleejordan]

Do you have another name you could use instead of "Integrated?" Ours is called what it is because of the heritage of the PowerShell Integrated Scripting Environment, which is what existed before the era of Visual Studio Code (and is what we hope the PowerShell Extension for VS Code can replace for our users). I'm saying we'd be unlikely to change the name from "PowerShell Integrated Console" because not only do users of the extension already know it is as that, but that users are familiar with the name since well before VS Code existed.

What if you named it "PowerShell (Code Hooks)" since it sounds like what's happening is your injecting hooks for VS Code into that spawned shell?

[Tyriar]

@andschwa this is a feature in other terminals and it's always referred to as "shell integration". We will also do this for all shells, so bash (Integrated), zsh (Integrated), etc. was the thinking there too.

"Code Hooks" doesn't mean much to me, even "VS Code Hooks" would be much more ambiguous than Integrated.

(Shell Integration) is an option but it's awfully long and could cause space troubles, especially when considering internationalization.

[andyleejordan]

Ah, I see. There are a lot of name conflicts (iTerm2 is already using this term, so is "Kitty" whatever terminal emulator that is). But moreover, VS Code already chose to name the terminals "Integrated Terminals" (which might also cause confusion for Code users with respect to this new feature creating even-more-integrated Integrated Terminals, and already causes confusing for users of the PowerShell Extension). Perhaps we can come up with a better name for the extension-bound terminal, but it will be a big user-facing change. /cc @SydneyhSmith

Kind of seems like both this feature and our extension need a name other than "Integrated" to avoid conflicts with Code's "Integrated Terminals."

[Tyriar]

@andschwa good point how it's an "shell integrated integrated terminal", we're thinking about this problem. @meganrogge suggested "enhanced", which may be ambiguous to some but could encourage trying it out. Using a setting instead of separate profiles for it is another option, but I worry about the confusion it would cause when configuring profiles.

Have you considered changing the extension's one to simply "PowerShell Extension" or "PowerShell Environment"? I never liked how long the name was as it often got truncated in the old dropdown (which you can still use). I know changing a name like this can be a pain though.

[andyleejordan]

It's hard when everything we do is literally about integrating one thing with another, so it's become a very overloaded term 🤣

[Tyriar]

@andschwa the pwsh extension might want to leverage shell integration when it's stable too 😉

[andyleejordan]

We'll have to integrate the integration into our integrated integration 😂

[meganrogge]

We've decided we'll run them as arguments to profiles