Open DHowett-MSFT opened 5 years ago
FWIW: You can find the path to defaults.json
fairly easily with Get-AppxPackage
. It won't work well for the unpackaged launch scenario, but it's not one we're really officially supporting.
Join-Path ((Get-AppxPackage Microsoft.WindowsTerminal).InstallLocation) "defaults.json"
"C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_0.5.2661.0_x64__8wekyb3d8bbwe\defaults.json"
I think the best way to do this would be similar to how get-module operates, where by default it only gets the settings explicitly specified in the user profile, whereas adding a "-All" switch to the command would get the full settings including the merged items.
This would be easy to process with Microsoft.Extensions.Configuration but that's a big dependency to take.
Also, the new "well known" dynamic profiles I think should be queryable with a well known parameter flag, e.g. Get-MSTerminalProfile -Dynamic PowerShellCore
I'll look into PRing these changes if I get some time.
@DHowett-MSFT The best option for implementation looks like:
Could also try to merge the nested objects but that'd be much uglier than just merging hashtables, I supposed they could be re-output as PSCustomObjects with a recursive function so as not to be a breaking change.
0.5 introduced a new base settings file,
defaults.json
. It's loaded before user settings, and any profiles with matching GUIDs (or GUIDs + sources) have their settings applied on top of any preexisting ones.A pleasant side effect of that is that anything set in defaults that's set to the same value in the user's settings file can be removed from the user's settings. That'll let Terminal regain control of that setting (for better or for worse.) The user settings emitted by default are a lot smaller thanks to this.
It'd be neat if MSTerminalSettings could look up the location of
defaults.json
, parse it, and strip out anything from the user settings that matches the default value.consideration:
guid
,name
,source
,hidden
These keys should probably be kept, even if they're the same.
name
andguid
are really helpful for users to identify their profiles (and Terminal usesguid
andsource
as a primary key.)consideration:
globals
/ root-level settingsWe moved to
globals
because our JSON serializer was being obnoxious and did not allow us to make sure that all global settings were printed at the top of the file. :smile: The new defaults and the new user settings "stub" dispensed with theglobals
object, but if it's present it'll be preferred over root-level settings.consideration: dynamic profiles
The preexisting powershell core and WSL profiles have "defaults" that don't exist in any knowable json file; we should totally rectify that. I guess their settings could be stripped out if they matched the cmd profile's settings ... they're close enough.
What do you think?