starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Terminal Preview settings file references the Stable schema #9152

New Issue
Closed
opened 2026-01-31 01:47:16 +00:00 by claunia · 11 comments
claunia commented 2026-01-31 01:47:16 +00:00
Owner
Copy Link

Originally created by @electronic-dk on GitHub (Jun 19, 2020).

The settings schema 1.0 doesn't have "compact" option for the tabWidthMode setting.
Terminal Preview 1.1.1671.0 references https://raw.githubusercontent.com/microsoft/terminal/release-1.0/doc/cascadia/profiles.schema.json Now when the terminal preview and the stable versions have diverged, it appears that schema needs to diverge as well.

Originally created by @electronic-dk on GitHub (Jun 19, 2020). The settings schema 1.0 doesn't have "compact" option for the tabWidthMode setting. Terminal Preview 1.1.1671.0 references https://raw.githubusercontent.com/microsoft/terminal/release-1.0/doc/cascadia/profiles.schema.json Now when the terminal preview and the stable versions have diverged, it appears that schema needs to diverge as well.
claunia commented 2026-01-31 01:47:17 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jun 19, 2020):

I'm not sure there's a good way for us to differentiate the two. We could change the aka.ms link to point at a different location for the preview build, but then users who just copy-paste their settings over from the release to the preview version would lose the preview URL. Hmmmmm

@zadjii-msft commented on GitHub (Jun 19, 2020): I'm not sure there's a good way for us to differentiate the two. We could change the aka.ms link to point at a different location for the preview build, but then users who just copy-paste their settings over from the release to the preview version would lose the preview URL. Hmmmmm
claunia commented 2026-01-31 01:47:18 +00:00
Author
Owner
Copy Link

@electronic-dk commented on GitHub (Jun 19, 2020):

@zadjii-msft I'd say that blindly copy-pasting stuff, especially configs of different versions of an app isn't the best thing in the world :) What about building in a "settings import tool" into the Terminal which would fix the schema upon importing (potentially among other things)? Or a settings migration tool. It would probably sit well within the future Settings UI. It may be a bit of an overkill though...

@electronic-dk commented on GitHub (Jun 19, 2020): @zadjii-msft I'd say that blindly copy-pasting stuff, especially configs of different versions of an app isn't the best thing in the world :) What about building in a "settings import tool" into the Terminal which would fix the schema upon importing (potentially among other things)? Or a settings migration tool. It would probably sit well within the future Settings UI. It may be a bit of an overkill though...
claunia commented 2026-01-31 01:47:18 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jun 26, 2020):

This is definitely something we'll need some code to back up, too. Ugh. Thank you.

@DHowett commented on GitHub (Jun 26, 2020): This is definitely something we'll need some code to back up, too. Ugh. Thank you.
claunia commented 2026-01-31 01:47:18 +00:00
Author
Owner
Copy Link

@Lunchb0ne commented on GitHub (Jul 12, 2020):

I'm not sure there's a good way for us to differentiate the two. We could change the aka.ms link to point at a different location for the preview build, but then users who just copy-paste their settings over from the release to the preview version would lose the preview URL. Hmmmmm

I'd say it's better to have the schema-url to automatically follow the channel via which it is created

@Lunchb0ne commented on GitHub (Jul 12, 2020): > I'm not sure there's a good way for us to differentiate the two. We could change the aka.ms link to point at a different location for the preview build, but then users who just copy-paste their settings over from the release to the preview version would lose the preview URL. Hmmmmm I'd say it's better to have the schema-url to automatically follow the channel via which it is created
claunia commented 2026-01-31 01:47:18 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Aug 19, 2020):

A brainblast I had while responding to #7341 - what if we had two aka.ms links, one for the preview and one for the stable schemas. When we lay down the userDefaults.json, let's stomp in the appropriate URL.

People currently on preview would need to update the URL manually, but that's not too bad. Current stable users would still get the stable schema, and new preview users would get the preview one.

I've apparently had this thought before, but now that it's a new day, I'm gonna say this is fine.

@zadjii-msft commented on GitHub (Aug 19, 2020): A brainblast I had while responding to #7341 - what if we had two aka.ms links, one for the preview and one for the stable schemas. When we lay down the userDefaults.json, let's stomp in the appropriate URL. People currently on preview would need to update the URL manually, but that's not too bad. Current stable users would still get the stable schema, and new preview users would get the preview one. I've apparently had this thought before, but now that it's a new day, I'm gonna say _this is fine_.
claunia commented 2026-01-31 01:47:19 +00:00
Author
Owner
Copy Link

@WSLUser commented on GitHub (Aug 20, 2020):

https://raw.githubusercontent.com/microsoft/terminal/master/doc/cascadia/profiles.schema.json contains the latest and greatest schema as it gets updated. But the alwaysOnTop, largePasteWarning and multiLinePasteWarning properties are considered "not allowed". I don't see an issue for that so I'll raise one.

Update: https://github.com/microsoft/terminal/issues/7353 filed.

Update 2: Apparently global settings aren't supposed to go under "defaults" but rather above it. But that's rather unorganized to me.

@WSLUser commented on GitHub (Aug 20, 2020): https://raw.githubusercontent.com/microsoft/terminal/master/doc/cascadia/profiles.schema.json contains the latest and greatest schema as it gets updated. But the `alwaysOnTop`, `largePasteWarning` and `multiLinePasteWarning` properties are considered "not allowed". I don't see an issue for that so I'll raise one. Update: https://github.com/microsoft/terminal/issues/7353 filed. Update 2: Apparently global settings aren't supposed to go under "defaults" but rather above it. But that's rather unorganized to me.
claunia commented 2026-01-31 01:47:19 +00:00
Author
Owner
Copy Link

@pedrolamas commented on GitHub (Nov 12, 2020):

Why not do something more on the lines of:

@pedrolamas commented on GitHub (Nov 12, 2020): Why not do something more on the lines of: - if non-preview, then use schema as "https://aka.ms/terminal-profiles-schema" - if preview, then use schema as "https://raw.githubusercontent.com/microsoft/terminal/TAG/doc/cascadia/profiles.schema.json", replacing tag with current app version (matching the GitHub tag)
claunia commented 2026-01-31 01:47:19 +00:00
Author
Owner
Copy Link

@xiiok commented on GitHub (Nov 16, 2020):

I like the idea of a dynamic userDefaults.json but is that something better addressed in the Settings UI effort?
In the meantime, since everyone must modify their settings.json directly anyway, here's my stopgap thought for userDefaults.json:

{
    // In order to receive the correct schema, comment/uncomment the $schema below according to the release you have installed.

    // Stable Release:
    "$schema": "https://aka.ms/terminal-profiles-schema",

    // Preview Release:
    // "$schema": "https://aka.ms/terminal-profiles-schema-preview",

Maybe someone else can wordsmith the first comment better? I can't tell if I made it too wordy.

The preview schema link can be:

@xiiok commented on GitHub (Nov 16, 2020): I like the idea of a dynamic `userDefaults.json` but is that something better addressed in the Settings UI effort? In the meantime, since everyone must modify their `settings.json` directly anyway, here's my stopgap thought for `userDefaults.json`: ``` { // In order to receive the correct schema, comment/uncomment the $schema below according to the release you have installed. // Stable Release: "$schema": "https://aka.ms/terminal-profiles-schema", // Preview Release: // "$schema": "https://aka.ms/terminal-profiles-schema-preview", ``` Maybe someone else can wordsmith the first comment better? I can't tell if I made it too wordy. The preview schema link can be: - A new aka.ms link such as the example in the code block above (preferred) - Someone or something is updating the current aka.ms link destination as it currently points to the latest stable https://raw.githubusercontent.com/microsoft/terminal/release-1.4/doc/cascadia/profiles.schema.json - The same update would naturally need to take place for the latest preview https://raw.githubusercontent.com/microsoft/terminal/release-1.5/doc/cascadia/profiles.schema.json - A direct link to the latest preview release of `profiles.schema.json` - Would require manually updating `userDefaults.json` with each release https://raw.githubusercontent.com/microsoft/terminal/release-1.5/doc/cascadia/profiles.schema.json - A direct link to the latest merged `profiles.schema.json` - Would not require manually updating `userDefaults.json`, but at times preview users may see settings referenced that haven't been released to them yet https://raw.githubusercontent.com/microsoft/terminal/main/doc/cascadia/profiles.schema.json
claunia commented 2026-01-31 01:47:19 +00:00
Author
Owner
Copy Link

@Lunchb0ne commented on GitHub (Nov 17, 2020):

Yeah, and the user settings can be automatically edited to use the correct schema based on the last wt version that was opened, so If I had WT-Preview running then it can change the schema URL to the shortlik for preview schema. If I had WT-Release running, the JSON is automatically edited so It points to the release schema.

@Lunchb0ne commented on GitHub (Nov 17, 2020): Yeah, and the user settings can be automatically edited to use the correct schema based on the last wt version that was opened, so If I had WT-Preview running then it can change the schema URL to the shortlik for preview schema. If I had WT-Release running, the JSON is automatically edited so It points to the release schema.
claunia commented 2026-01-31 01:47:19 +00:00
Author
Owner
Copy Link

@xiiok commented on GitHub (Nov 17, 2020):

That's for sure the ideal implementation. But I'm wondering if that effort should simply be a part of the broader full blown Settings UI feature. In the meantime what I suggested would still be a manual effort, but at least both links would be available in userDefaults.json and it'd be clear to users which link they need to use (since everyone already has to open up their settings.json to configure any settings already).

I don't want to cause any unnecessary scope creep on whomever is working on the Settings UI though 😁 imo there needs to be some level of concurrence here since no matter how you approach this particular issue, there's broader implications for other features in the works.

@xiiok commented on GitHub (Nov 17, 2020): That's for sure the ideal implementation. But I'm wondering if that effort should simply be a part of the broader full blown Settings UI feature. In the meantime what I suggested would still be a manual effort, but at least both links would be available in `userDefaults.json` and it'd be clear to users which link they need to use (since everyone already has to open up their `settings.json` to configure any settings already). I don't want to cause any unnecessary scope creep on whomever is working on the Settings UI though 😁 imo there needs to be some level of concurrence here since no matter how you approach this particular issue, there's broader implications for other features in the works.
claunia commented 2026-01-31 01:47:20 +00:00
Author
Owner
Copy Link

@giggio commented on GitHub (Aug 2, 2023):

Why not do something more on the lines of:

The problem of using the main branch is that it might have schema that has not yet been released.
If there were release and a prerelease branches the aka.ms links would be unnecessary, we could just use a raw.githubusercontent url directly pointing to the profiles.schema.json at the specific branch. main should only be used for the ones building Terminal themselves (I was one of those and I used main for years).

To the team: do you think that having such branches makes sense?

@giggio commented on GitHub (Aug 2, 2023): > Why not do something more on the lines of: > > * if non-preview, then use schema as "[aka.ms/terminal-profiles-schema](https://aka.ms/terminal-profiles-schema)" > * if preview, then use schema as "[`TAG`/doc/cascadia/profiles.schema.json (raw)](https://raw.githubusercontent.com/microsoft/terminal/TAG/doc/cascadia/profiles.schema.json)", replacing tag with current app version (matching the GitHub tag) The problem of using the `main` branch is that it might have schema that has not yet been released. If there were `release` and a `prerelease` branches the aka.ms links would be unnecessary, we could just use a raw.githubusercontent url directly pointing to the `profiles.schema.json` at the specific branch. `main` should only be used for the ones building Terminal themselves (I was one of those and I used `main` for years). To the team: do you think that having such branches makes sense?
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-Schema In-PR Issue-Docs Needs-Tag-Fix Priority-3 Product-Terminal
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#9152
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?