Terminal: Add support for roaming settings.json or storing it elsewhere

[patriksvensson]

Description of the new feature/enhancement

I have three different computers that I use for work. I keep my PowerShell profile in a GitHub repository and dot source it in my local PowerShell profile. That way I will only need to do a git pull on my profile repository to get all changes propagated on each computer.

It would be great if I could do something similar with my Windows Terminal settings by simply stating in my local settings.json file that the "real" settings could be found somewhere else.

(It could even be that the loaded profile acts like a base for the settings on the computer so things could be overridden, but that is a completely different issue that remains to be opened)

I'm aware that I might have overlooked something here, but would love to start a discussion about this since I suspect that I'm not the only one with this "problem".

Proposed technical implementation details (optional)

{
    "$schema": "https://aka.ms/terminal-profiles-schema",
    "globals": {
        "loadProfileFrom": "C:/Source/git/profiles/terminal_profile.json"
    }

[brandonh-msft]

any reason we can't just use the UWP Roaming data store?
https://docs.microsoft.com/en-us/windows/uwp/design/app-settings/store-and-retrieve-app-data#roaming-data

I know this isn't a _true_ UWP app, but Centennials can still use the UWP APIs, right?

[DHowett-MSFT]

We actually used to roam your settings using those exact APIs, but it caused us way more headache than it was worth. There’s a couple things we need to nail before we consider turning roaming back on.

[brandonh-msft]

yeah was just coming back to edit.

looks like per here: https://docs.microsoft.com/en-us/windows/apps/desktop/modernize/desktop-to-uwp-enhance
and here: https://docs.microsoft.com/en-us/windows/apps/desktop/modernize/desktop-to-uwp-supported-api

we can't simply use RoamingFolder as I'd hoped? In lieu of this, then, @patriksvensson's approach is probably the best we'll get and users - well I, for one - could simply point at a OneDrive (or similar) location.

[zadjii-msft]

I'm more using this issue as a tracker for "add a way to import settings from other paths" than a "re-enable settings roaming". Using RoamingState for storing the settings was a pain. However, I think that we all agree adding support for importing settings from another location is a good idea, but one that needs careful thought and preferably a spec to go with it.

This is even a scenario referenced in the original cascading settings spec, as something we could consider in the future.

1770 was the original bug tracking disabling roaming settings. Note the pile of other issues that were dupe'd to it.

[patriksvensson]

@zadjii-msft What's the process for creating a spec for something? Do you have an RFC-process or similar?

[zadjii-msft]

@patriksvensson We don't have an official "RFC" process, but we do have a semi-formal spec review process. This helps us ensure the entire team is on-board with more complicated features, and for scenarios like this one, some of the more complicated edge cases have been thought out. I'd refer to the following:

• Contributing-to a Spec
• The spec template
• completed specs
• all spec PRs

[patriksvensson]

@zadjii-msft Would it help if I (or someone else) drafted up a spec to get the ball rolling?

[zadjii-msft]

I think that would be _very_ helpful :)

[jpetkau]

As a workaround for this, it's possible to make profiles.json a symlink to a shared settings file in Roaming or OneDrive or Dropbox or whatever.

This mostly works, except terminal doesn't notice changes to the actual file. It only watches the symlink. So hot-reloading of changes doesn't work.

Of course roaming just magically working would be better.

[chwarr]

There's a related issue in this space, #4566 "Consider adding a WT_PROFILE env var pointing to settings file for 1.0 release".

It proposes setting the environment variable WT_PROFILE to the path of the user's settings file. Copying a comment that I made on that here:

My expectation of a variable like WT_PROFILE would be that I could [also] use it to change where Windows Terminal reads user settings from. ...

Based on how other, similar software works, I think it would make sense if Windows Terminal only read this environment variable at process start up and then monitored the path for changes. It would also be reasonable for Windows Terminal to detect changes to the environment "template" by handling WM_SETTINGCHANGE notifications. (Though, there are some subtle details to consider about when changes are applied. Lots of thoughts in #1125, "Feature Request: Terminal should listen for the WM_SETTINGCHANGE for environment variable updates".)

[patriksvensson]

If anyone is interested in an interim solution to this, I've written some instructions here: https://www.patriksvensson.se/2019/12/roaming-profiles-with-windows-terminal

[DavidGamba]

If the file watcher that monitors profiles.json can detect a symlink and watch the target instead many users would easily backup their config in multiple ways and still get the full benefits of hot reload of the config.

[DavidGamba]

If the file watcher that monitors profiles.json can detect a symlink and watch the target instead many users would easily backup their config in multiple ways and still get the full benefits of hot reload of the config.

[zadjii-msft]

From @MartinSGill in #5638

Proposed technical implementation details (optional)

The common linux practice of using a settings.d style folder and loading all files in that folder seems like a good approach to me.

* Settings.json defines an "include" directory (environment variables permitted)

* Settings loads all files in that folder in alphabetical order.

* Settings adds/overrides settings based on loaded files.

* Additional files would all have the same structure/schema as the default settings.json

* [Extra Credit] Support multiple folders, allow shared/user settings.

[MartinSGill]

Advantages I see for my proposed implementation:

• it would support tools such as chef/ansible to install "features".
• It would also allow sharing of themes/keyboard-maps etc without upsetting the current settings. Add the file you want to try out to load last, try it out, if you don't like it, just delete the file.
• It would allow you to make profiles portable (e.g. CloudDrive/Dropbox)