Make it possible to use an existing profile if an app is launched via defterm #10952
Labels
Area-DefApp
Issue-Task
It's a feature request, but it doesn't really need a major design.
Product-Terminal
The new Windows Terminal.
Resolution-Fix-Committed
Fix is checked in, but it might be 3-4 weeks until a release.
Milestone
Comments
dhrdlicka
added
the
Issue-Feature
ghost
added
Needs-Triage
|
I'm pretty sure part of "what's defined in registry or shortcuts" would include the existing profiles. When that feature is added, passing those existing profiles off to the registry would almost certainly be a hard requirement for precisely the use-case you bring up here. |
|
I did think that I had a feature logged for this but I cannot find it. It might have just been a feature in my head. I would like to perform some sort of matching against the profiles and left provisions in for passing this sort of information around in at least a few places. |
zadjii-msft
added
Issue-Task
DHowett
added a commit
that referenced
this issue
Aug 23, 2021
Right now, we store GUIDs in panes and most of the functions for interacting with profiles on the settings model take GUIDs and look up profiles. This pull request changes how we store and look up profiles to prefer profile objects. Panes store strong references to their originating profiles, which simplifies settings lookup for CloseOnExit and the bell settings. In fact, deleting a pane's profile no longer causes it to forget which CloseOnExit setting applies to it. Duplicating a pane that is hosting a deleted profile (#5047) now duplicates the profile, even though it is otherwise unreachable. This makes the world more consistent and allows us to _eventually_ support panes hosting profiles that do not have GUIDs that can be looked up in the profile list. This is a gateway to #6776 and #10669, and consolidating the profile lookup logic will help with #10952. PR #10588 introduced TerminalSettings::CreateWithProfile and made ...CreateWithProfileByID a thin wrapper over top it, which looked up the profile by GUID before proceeding. It has also been removed, as its last caller is gone. Closes #5047
ghost
pushed a commit
that referenced
this issue
Aug 25, 2021
This pull request introduces our first use of the "base" profile as an actual profile. Incoming commandlines from `wt foo` *and* default terminal handoffs will be hosted in the base profile. **THIS IS A BREAKING CHANGE** for user behavior. The original behavior where commandlines were hosted in the "default" profile (in most cases, Windows PowerShell) led to user confusion: "why does cmd use my powershell icon?" and "why does the title say PowerShell?". Making this change unifies the user experience so that we can land commandline detection in #10952. Users who want the original behavior can get it back for commandline invocation by specifying a profile using the `-p` argument, as in `wt -p PowerShell -- cmd`. As a temporary stopgap, users who attempt to duplicate the base profile will get their specified default profile until we land #5047. This feature is hidden behind the same feature flag that controls the visibility of base/"Defaults" in the settings UI. Fixes #10669 Related to #6776
DHowett
removed
the
Needs-Triage
3 tasks
ghost
pushed a commit
that referenced
this issue
Oct 8, 2021
This implements command line matching for `CascadiaSettings::GetProfileForArgs`.
The command lines for all user profiles are resolved to absolute file paths,
argument quotes are standardized ("canonicalized") and the results are cached.
When `GetProfileForArgs` is called with a Commandline() value, we "canonicalize"
the argument as well and find the profile that is the longest prefix.
If none could be found the default profile is returned.
## PR Checklist
* [x] Closes #9458
* [x] Closes #10952
* [x] I work here
* [ ] Tests added/passed
## Validation Steps Performed
* Open a `cmd.exe` tab in the store-version of WT
* Run `start cmd`
--> A tab with the `cmd.exe` profile opens
* Run `start pwsh.exe`
--> A tab with the PowerShell 7 profile opens
* Run PowerShell 7 from the start menu
--> A tab with the PowerShell 7 profile opens
* Create a symlink for PowerShell 7 and launch `pwsh.exe` from there
--> A tab with the PowerShell 7 profile opens
ghost
added
Resolution-Fix-Committed
|
🎉This issue was addressed in #11390, which has now been successfully released as Handy links: |
This issue was closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description of the new feature/enhancement
There should be an option to check whether there is a profile that would match the command line of a console app launched when Terminal is set as default and use that profile.
This would be a nice alternative to using the conhost configuration (#9458) as some people might prefer to use their already defined profiles rather than what's defined in the registry or shortcuts.
Proposed technical implementation details (optional)
Some extra thought should be given to handling command line arguments in both the profile's
commandLineand the launched app's command line. A sane compromise could be that a launched app's command line would only matchcommandLinewith either the exact same arguments or none at all to make sure thatcmd.exedoesn't get launched with a profile defined for some batch file.The text was updated successfully, but these errors were encountered: