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 should take user configs more seriously #22453

New Issue
Open
opened 2026-01-31 08:13:37 +00:00 by claunia · 0 comments
claunia commented 2026-01-31 08:13:37 +00:00
Owner
Copy Link

Originally created by @ebarzilay-godaddy on GitHub (Oct 26, 2024).

Description of the new feature

Pre disclaimer: this is going to be long, opinionated to some extent, and arguably would be a better fit for a discussion. The reason I chose to file this as a feature request is because I want to avoid making this into some lengthy discussion. Hopefully what I write would be considered a valid point. In the worst case, feel free to tell me that it is what it is, and maybe move it into a discussion. You could also claim that this is a kind of a weird thing to do given the problem in #5763 (probably more).

The TL;DR of it is that it would be awfully nice if the Terminal would take my settings more seriously, in the same way that VSCode does (and probably took considerable efforts to do so). I know (very well, as will be evident below) that it does keep "most" of my settings, which is IMO a base minimum expectation from all software (ie, not losing my config), but it does so in a way that is discouraging further tweaks by power users -- and I think that a large part of the target users are just that.

I'll start by describing the actual issue that I deal with. I've been an enthusiastic user of Terminal from very early on. But one problem that I fight with way too often is that every time Terminal is updated, it shows complete disregard for my feelings by making itself an unwelcome guest into my settings file. Stuff gets reshuffled in random order, values get added or removed, comments dropped, etc.

It actually got so tedious with the recent update being my last straw: I just wrote some code that has my complete config, and can compare it with whatever the update butchered my config into. I did this so I can see what the actual changes were, change my config if needed (eg, I need to go and figure out if the new id fields for commands are actually needed or not), and then re-generate after adapting it.

I know that it's something that is probably rare due to the issue in #5763, but to clear that up: whenever I setup a new machine, I do something like

cd %LocalAppData%\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState
del settings.json
mklink settings.json C:\my-wsl-home-dir\.winterm.json

so I get to keep my settings in my home directory, and from there I sync it across different machines.

Just to give some random examples:

  • I have the items in actions grouped+sorted in a way that makes sense. Updates shuffles them. Always.

  • For things like profiles or schemes, I have the name entry first, which makes sense to me since I'm a human. Updates sorts the keys, moving the name to some random place in the middle of the list. It makes sense for software to do that, since it's not human. [Add obligatory No Country quote about "man and steer" here...]

  • Any use of GUIDs is another example of a man vs machine kind of a thing. Profiles have a name field, why not use that instead of indirecting through a GUID? (Part of what made this a last-straw, since with generating the settings via code I can add bindings for the GUIDs, which makes the source config more human friendly.)

  • Comments. I like that the settings parsing allows comments instead of insisting on some well formed JSON. It shows a pull in a good direction -- but dropping these comments on an update is pulling it in the opposite direction.

So my complaint -- or rather, my feature request, is at a highlevel of everything around dealing with the settings. What I'm requesting is more than just some incremental improvements (though the implementation could take incremental steps). Instead, the feature I'm requesting is a highlevel principle of respecting the config situation as a first class respected thing, rather than the much weaker current situation of "why not let people tweak stuff".

Overall, like I said, I'm well aware that doing something like this is a significant effort.

But like I said, VSCode sets a precedent of doing just that -- and doing so in a very nice & consistent way, preserving comments, or commas at the end of an attribute list (ie, the thing that is a popular code style, but not a JSON thing). In fact, VSCode does that so well, that I wouldn't be surprised if there's some that could get ripped out as a reusable library for doing this (or maybe that already exists).

Since this is a strange high-level feature request, feel free to move it, or to close it if it's already discussed, or whatever.

Thanks for listening.

Proposed technical implementation details

(Did I mention doing the same thing VSCode is doing... 😃)

Originally created by @ebarzilay-godaddy on GitHub (Oct 26, 2024). ### Description of the new feature Pre disclaimer: this is going to be long, opinionated to some extent, and arguably would be a better fit for a discussion. The reason I chose to file this as a feature request is because I want to avoid making this into some lengthy discussion. Hopefully what I write would be considered a valid point. In the worst case, feel free to tell me that it is what it is, and maybe move it into a discussion. You could also claim that this is a kind of a weird thing to do given the problem in #5763 (probably more). The TL;DR of it is that it would be awfully nice if the Terminal would take my settings more seriously, in the same way that VSCode does (and probably took considerable efforts to do so). I know (very well, as will be evident below) that it does keep "most" of my settings, which is IMO a base minimum expectation from all software (ie, not losing my config), but it does so in a way that is discouraging further tweaks by power users -- and I think that a large part of the target users are just that. I'll start by describing the actual issue that I deal with. I've been an enthusiastic user of Terminal from very early on. But one problem that I fight with way too often is that every time Terminal is updated, it shows complete disregard for my feelings by making itself an unwelcome guest into my settings file. Stuff gets reshuffled in random order, values get added or removed, comments dropped, etc. It actually got so tedious with the recent update being my last straw: I just wrote some code that has my complete config, and can compare it with whatever the update butchered my config into. I did this so I can see what the actual changes were, change my config if needed (eg, I need to go and figure out if the new `id` fields for commands are actually needed or not), and then re-generate after adapting it. I know that it's something that is probably rare due to the issue in #5763, but to clear that up: whenever I setup a new machine, I do something like ``` cd %LocalAppData%\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState del settings.json mklink settings.json C:\my-wsl-home-dir\.winterm.json ``` so I get to keep my settings in my home directory, and from there I sync it across different machines. Just to give some random examples: * I have the items in `actions` grouped+sorted in a way that makes sense. Updates shuffles them. Always. * For things like profiles or schemes, I have the `name` entry first, which makes sense to me since I'm a human. Updates sorts the keys, moving the `name` to some random place in the middle of the list. It makes sense for software to do that, since it's not human. [Add obligatory No Country quote about "man and steer" here...] * Any use of GUIDs is another example of a man vs machine kind of a thing. Profiles have a `name` field, why not use that instead of indirecting through a GUID? (Part of what made this a last-straw, since with generating the settings via code I can add bindings for the GUIDs, which makes the source config more human friendly.) * Comments. I like that the settings parsing allows comments instead of insisting on some well formed JSON. It shows a pull in a good direction -- but dropping these comments on an update is pulling it in the opposite direction. So my complaint -- or rather, my feature request, is at a highlevel of everything around dealing with the settings. What I'm requesting is more than just some incremental improvements (though the implementation could take incremental steps). Instead, the feature I'm requesting is a highlevel principle of respecting the config situation as a first class respected thing, rather than the much weaker current situation of "why not let people tweak stuff". --- Overall, like I said, I'm well aware that doing something like this is a significant effort. But like I said, VSCode sets a precedent of doing just that -- and doing so in a very nice & consistent way, preserving comments, or commas at the end of an attribute list (ie, the thing that is a popular code style, but not a JSON thing). In fact, VSCode does that so well, that I wouldn't be surprised if there's some that could get ripped out as a reusable library for doing this (or maybe that already exists). --- Since this is a strange high-level feature request, feel free to move it, or to close it if it's already discussed, or whatever. Thanks for listening. ### Proposed technical implementation details (Did I mention doing the same thing VSCode is doing... 😃)
claunia added the Issue-FeatureResolution-Duplicate labels 2026-01-31 08:13:37 +00:00
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 Issue-Feature Resolution-Duplicate
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#22453
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?