Switching OS input method resets Terminal colors and zoom #15558

@zadjii-msft commented on GitHub (Oct 18, 2021):

Hmm. This is a decent point. We reload the settings when we get a keyboard layout change. This is important for things like the actions, who might need to be re-parsed for different keys in the new layout. But this is something that's totally unrelated that's getting blown away.

I'm running into a similar issue with the work in ragnarok for #5000. If you set the colors with VT, then hot-reload the settings, we'll remove the changes to those colors. (same with font size, opacity, anything that can get changed at runtime really). The question is - does a change to the settings override a runtime change by the user? And I think I'm leaning "it probably shouldn't". But then you get into weird things like "should 'preview color scheme' still work on top of the user setting the colors with VT" and then I lean "yes it should"

@zadjii-msft commented on GitHub (Oct 18, 2021): Hmm. This is a decent point. We reload the settings when we get a keyboard layout change. This is important for things like the actions, who might need to be re-parsed for different keys in the new layout. But this is something that's totally unrelated that's getting blown away. I'm running into a similar issue with the work in `ragnarok` for #5000. If you set the colors with VT, then hot-reload the settings, we'll remove the changes to those colors. (same with font size, opacity, anything that can get changed at runtime really). The question is - does a change to the settings override a runtime change by the user? And I think I'm leaning "it probably shouldn't". But then you get into weird things like "should 'preview color scheme' still work on top of the user setting the colors with VT" and then I lean "yes it should"

claunia commented

@antoineco commented on GitHub (Oct 18, 2021):

I think it is acceptable to expect the settings to be reloaded when certain things change.

I was just surprised to see something, which seemed unrelated to me, cause a reload in Terminal.

If this is not something that can (or should) be avoided, I'm also fine closing as "works as intended". At least the issue should contain enough keywords for someone to find it if they run into a similar issue.

@antoineco commented on GitHub (Oct 18, 2021): I think it is acceptable to expect the settings to be reloaded when certain things change. I was just surprised to see something, which seemed unrelated to me, cause a reload in Terminal. If this is not something that can (or should) be avoided, I'm also fine closing as "works as intended". At least the issue should contain enough keywords for someone to find it if they run into a similar issue.

claunia commented

@zadjii-msft commented on GitHub (Oct 19, 2021):

I think I'm actually gonna leave this open. I think I've got an idea in my notes for now to get this to work. Setting the colors with VT will set a runtime "colors have been overridden" flag, and previewing a scheme will clear that flag out. But a plain-old settings reload, that won't touch that flag, so that'll allow the vt-set colors to persist across hot-reloads of the settings. We might be able to get even more precise and determine that the color scheme for a profile changed, and in that scenario, also clear out the flag.

A bunch of work really, but definitely possible.

@zadjii-msft commented on GitHub (Oct 19, 2021): I think I'm actually gonna leave this open. I think I've got an idea in my notes for now to get this to work. Setting the colors with VT will set a runtime "colors have been overridden" flag, and previewing a scheme will clear that flag out. But a plain-old settings reload, that won't touch that flag, so that'll allow the vt-set colors to persist across hot-reloads of the settings. We might be able to get even more precise and determine that the color scheme for a profile changed, and in that scenario, also clear out the flag. A bunch of work really, but definitely possible.

claunia commented

@j4james commented on GitHub (Oct 19, 2021):

Setting the colors with VT will set a runtime "colors have been overridden" flag, and previewing a scheme will clear that flag out.

Can't we just make it so that the settings dialog only updates properties that have actually been edited in some way? So if you change the color scheme for a profile, or edit something on the Color Schemes page, that'll override any colors that have been set programmatically, but if you edit something unrelated (like say the Actions page), then we leave the colors as they are.

This applies to other settings as well. If some application has left the cursor switched to an underscore when your preference is a block, you should be able to go to the Appearance page and reapply your preference by toggling the value or perhaps just clicking Save. It doesn't seem reasonable to me for an application to lock in changes to things like colors and the cursor so your only recourse is to close the tab and start again.

Following the principle of least astonishment:

If you edit something on the Actions page in the settings, would you be surprised if that also caused the colors in the terminal to be reset? I think the answer is probably "yes" (as seen from this issue), but perhaps not hugely surprising when you think about what might have triggered that change.
If you try and change the color scheme for your profile, would you be surprised if that didn't have any effect, just because some app sent a palette-altering VT sequence at some point in the past? In this case I think the answer is definitely "yes", and it would almost certainly be seen as a bug, because it's not at all obvious why it would have failed.

@j4james commented on GitHub (Oct 19, 2021): > Setting the colors with VT will set a runtime "colors have been overridden" flag, and previewing a scheme will clear that flag out. Can't we just make it so that the settings dialog only updates properties that have actually been edited in some way? So if you change the color scheme for a profile, or edit something on the _Color Schemes_ page, that'll override any colors that have been set programmatically, but if you edit something unrelated (like say the _Actions_ page), then we leave the colors as they are. This applies to other settings as well. If some application has left the cursor switched to an underscore when your preference is a block, you should be able to go to the _Appearance_ page and reapply your preference by toggling the value or perhaps just clicking _Save_. It doesn't seem reasonable to me for an application to lock in changes to things like colors and the cursor so your only recourse is to close the tab and start again. Following the [principle of least astonishment](https://en.wikipedia.org/wiki/Principle_of_least_astonishment): 1. If you edit something on the _Actions_ page in the settings, would you be surprised if that also caused the colors in the terminal to be reset? I think the answer is probably "yes" (as seen from this issue), but perhaps not hugely surprising when you think about what might have triggered that change. 2. If you try and change the color scheme for your profile, would you be surprised if that _didn't_ have any effect, just because some app sent a palette-altering VT sequence at some point in the past? In this case I think the answer is definitely "yes", and it would almost certainly be seen as a bug, because it's not at all obvious why it would have failed.

claunia commented

@zadjii-msft commented on GitHub (Oct 19, 2021):

Can't we just make it so that the settings dialog only updates properties that have actually been edited in some way? So if you change the color scheme for a profile, or edit something on the Color Schemes page, that'll override any colors that have been set programmatically, but if you edit something unrelated (like say the Actions page), then we leave the colors as they are.

I would love that. Unfortunately we don't really have the architecture in place at the moment to say "this part of the settings changed" 😞

@zadjii-msft commented on GitHub (Oct 19, 2021): > Can't we just make it so that the settings dialog only updates properties that have actually been edited in some way? So if you change the color scheme for a profile, or edit something on the Color Schemes page, that'll override any colors that have been set programmatically, but if you edit something unrelated (like say the Actions page), then we leave the colors as they are. I would _love_ that. Unfortunately we don't really have the architecture in place at the moment to say "this _part_ of the settings changed" 😞

claunia commented

@j4james commented on GitHub (Oct 19, 2021):

Unfortunately we don't really have the architecture in place at the moment to say "this part of the settings changed"

I get that, but I thought what you were proposing was going to take a bunch of work anyway, and would be a step backwards for the second scenario I described (assuming I've understood you correctly). So if anyone is going to be spending significant time on trying to fix this, it would be nice to try and get it right (assuming we're in agreement on what "right" is).

It could be something simple like saving the settings we care about (e.g. colors and cursor shapes) when the dialog is opened, and then when the user saves, you only apply those settings to any open tabs if the values have changed from what they were at the start.

@j4james commented on GitHub (Oct 19, 2021): > Unfortunately we don't really have the architecture in place at the moment to say "this part of the settings changed" I get that, but I thought what you were proposing was going to take a bunch of work anyway, and would be a step backwards for the second scenario I described (assuming I've understood you correctly). So if anyone is going to be spending significant time on trying to fix this, it would be nice to try and get it right (assuming we're in agreement on what "right" is). It could be something simple like saving the settings we care about (e.g. colors and cursor shapes) when the dialog is opened, and then when the user saves, you only apply those settings to any open tabs if the values have changed from what they were at the start.

claunia commented

@zadjii-msft commented on GitHub (Oct 21, 2021):

future self: 1aa2849d9 has the commit for the incredibly silly RUNTIME_PROPERTY

#define RUNTIME_PROPERTY(type, name, setting, ...)                \
private:                                                          \
    type _##name{ __VA_ARGS__ };                                  \
    std::optional<type> _runtime##name{ std::nullopt };           \
                                                                  \
public:                                                           \
    void name(const type newValue) { _runtime##name = newValue; } \
                                                                  \
    type name() const { return _runtime##name ? *_runtime##name : _##name; }

and then we'd stealth slide the updated settings into the _##name values when the settings are updated instead of just discarding the entire ControlSettings/ControlAppearance objects. That however is mildly breaking and probably out of scope for the refactor. Hence, leaving it here.

Kinda like #11067 also.

I'm trusting that dustin did the diligence searching.

@zadjii-msft commented on GitHub (Oct 21, 2021): future self: 1aa2849d9 has the commit for the incredibly silly `RUNTIME_PROPERTY` ```c++ #define RUNTIME_PROPERTY(type, name, setting, ...) \ private: \ type _##name{ __VA_ARGS__ }; \ std::optional<type> _runtime##name{ std::nullopt }; \ \ public: \ void name(const type newValue) { _runtime##name = newValue; } \ \ type name() const { return _runtime##name ? *_runtime##name : _##name; } ``` and then we'd stealth slide the updated settings into the `_##name` values when the settings are updated instead of just discarding the entire `ControlSettings`/`ControlAppearance` objects. That however is mildly breaking and probably out of scope for the refactor. Hence, leaving it here. Kinda like #11067 also. I'm trusting that dustin did the diligence searching.

claunia commented

@zadjii-msft commented on GitHub (Nov 29, 2021):

falling-asleep-thought: we could probably hook the language change notifier up to a method that only reloads the keybindings, since those are the only thing that would have changed. Seems like an easy solution....

@zadjii-msft commented on GitHub (Nov 29, 2021): falling-asleep-thought: we could probably hook the language change notifier up to a method that only reloads the _keybindings_, since those are the only thing that would have changed. Seems like an easy solution....

claunia commented

@pbl987 commented on GitHub (May 25, 2022):

I think i have a similiar problem. When i open an "admin" console, it gets a red admin color scheme assigned. (Picture 1).
When i then press Win + Space, it gets reset to standard. It also happens on other occasions, but i can't say why. (Picture 2).
Maybe it's like in the title.

@pbl987 commented on GitHub (May 25, 2022): I think i have a similiar problem. When i open an "admin" console, it gets a red admin color scheme assigned. (Picture 1). When i then press Win + Space, it gets reset to standard. It also happens on other occasions, but i can't say why. (Picture 2). Maybe it's like in the title. ![Screenshot 2022-05-26 003221](https://user-images.githubusercontent.com/28102804/170381271-92fea0cd-3bf8-4474-a002-ede50801ee3b.png) ![Screenshot 2022-05-26 003304](https://user-images.githubusercontent.com/28102804/170381283-f4c727c5-233c-4187-893d-2f39a93e5759.png) ![Screenshot 2022-05-26 003454](https://user-images.githubusercontent.com/28102804/170381293-806234c9-fed3-4b18-9361-580d259c5fbb.png)

claunia commented

@zadjii-msft commented on GitHub (May 26, 2022):

@pbl987 That's definitely this same bug. Might I interest you in the elevate setting, new in 1.13?

That'll let you mark a profile as requiring an admin window, and will automatically create an admin one if you're running unelevated. Then, you could just set the tab color and colorscheme for that elevate:true profile normally, and a language change won't blow them away 😉

@zadjii-msft commented on GitHub (May 26, 2022): @pbl987 That's definitely this same bug. Might I interest you in the `elevate` setting, new in 1.13? ![image](https://user-images.githubusercontent.com/18356694/170585670-c08732eb-8c06-4de9-9d7f-7b7d12bfcad6.png) That'll let you mark a profile as requiring an admin window, and will automatically create an admin one if you're running unelevated. Then, you could just set the tab color and colorscheme for that `elevate:true` profile normally, and a language change won't blow them away 😉

claunia commented

@pbl987 commented on GitHub (May 27, 2022):

@zadjii-msft I would love that. Thank you for working on this!

Reading the first posts, i got the impression that it's not a priority issue.
But (minor) stuff like that is really annoying, so i'm glad you guys are on it! :-)

By the way, the runas feature is also much-needed, as a non-professional it took me some time to figure out the parameters for the commandline and the escape sequences.
(original version had been this beauteousness :D :
"C:\Users\patrick\AppData\Local\Microsoft\WindowsApps\Microsoft.PowerShell_8wekyb3d8bbwe\pwsh.exe" -Command Start-Process -verb runas -Filepath "wt" -ArgumentList """-p """"PowerShell ```(Admin```)"""" --tabColor #E74856 --colorScheme Adminfarben"""
)

@pbl987 commented on GitHub (May 27, 2022): @zadjii-msft I would love that. Thank you for working on this! Reading the first posts, i got the impression that it's not a priority issue. But (minor) stuff like that is really annoying, so i'm glad you guys are on it! :-) By the way, the runas feature is also much-needed, as a non-professional it took me some time to figure out the parameters for the commandline and the escape sequences. (original version had been this beauteousness :D : `"C:\Users\patrick\AppData\Local\Microsoft\WindowsApps\Microsoft.PowerShell_8wekyb3d8bbwe\pwsh.exe" -Command Start-Process -verb runas -Filepath "wt" -ArgumentList """-p """"PowerShell ```(Admin```)"""" --tabColor #E74856 --colorScheme Adminfarben"""` )

claunia commented

@zadjii-msft commented on GitHub (May 27, 2022):

By the way, the runas feature is also much-needed, as a non-professional it took me some time to figure out the parameters for the commandline and the escape sequences

Yea, that's why the elevate setting is so great, now you can replace that whole commandline with just "C:\Users\patrick\AppData\Local\Microsoft\WindowsApps\Microsoft.PowerShell_8wekyb3d8bbwe\pwsh.exe" ☺️

@zadjii-msft commented on GitHub (May 27, 2022): > By the way, the runas feature is also much-needed, as a non-professional it took me some time to figure out the parameters for the commandline and the escape sequences Yea, that's why the elevate setting is so great, now you can replace that whole `commandline` with just `"C:\Users\patrick\AppData\Local\Microsoft\WindowsApps\Microsoft.PowerShell_8wekyb3d8bbwe\pwsh.exe"` ☺️

claunia commented

@vient commented on GitHub (Nov 30, 2022):

Please take a look at this 🙏🏼
It is uncomfortable to constantly adjust terminal zoom back when you forgot to change layout back to EN before switching to terminal window.

@vient commented on GitHub (Nov 30, 2022): Please take a look at this 🙏🏼 It is uncomfortable to constantly adjust terminal zoom back when you forgot to change layout back to EN before switching to terminal window.

claunia commented

@vient commented on GitHub (Nov 30, 2022):

So, my comment was marked as spam: is there any other mechanism to vote for issues? My point is that this issue is causing problems for anybody using more than one keyboard layout, yet it is not fixed more than year later.

I myself reported it three months ago, it was just marked as duplicate.

@vient commented on GitHub (Nov 30, 2022): So, my comment was marked as spam: is there any other mechanism to vote for issues? My point is that this issue is causing problems for anybody using more than one keyboard layout, yet it is not fixed more than year later. I myself reported it three months ago, it was just marked as duplicate.

claunia commented

@zadjii-msft commented on GitHub (Nov 30, 2022):

If you'd like to "+1" this feature, the best way to do that is by hitting the 👍 button on this issue

That way, you avoid unnecessarily pinging everyone following this thread. Thanks!

@zadjii-msft commented on GitHub (Nov 30, 2022): If you'd like to "+1" this feature, the best way to do that is by hitting the 👍 button on this issue ![image](https://user-images.githubusercontent.com/18356694/96140789-ef3c8880-0ec5-11eb-82e0-30ce4977b9a7.png) That way, you avoid unnecessarily pinging everyone following this thread. Thanks!

claunia commented

@vient commented on GitHub (Dec 6, 2022):

FYI: this behavior can be bypassed, in a way, by enabling Per-Window Keyboard Layout in Windows settings (I just thought "what if Windows could have per-window keyboard layouts" and well, it already has this functionality).

@vient commented on GitHub (Dec 6, 2022): FYI: this behavior can be bypassed, in a way, by enabling Per-Window Keyboard Layout in Windows settings (I just thought "what if Windows could have per-window keyboard layouts" and well, it already has this functionality).

claunia commented

@akaltar commented on GitHub (Apr 26, 2023):

Would like to add that this also resets the tab titles:

@akaltar commented on GitHub (Apr 26, 2023): Would like to add that this also resets the tab titles: ![before](https://user-images.githubusercontent.com/2000269/234548291-be6ee1d8-be22-4727-8eb1-b1a59f23b1a7.png) ![after](https://user-images.githubusercontent.com/2000269/234548349-beb4e5a0-c095-4bf3-9be7-708c2efd45cb.png)

claunia commented

@zadjii-msft commented on GitHub (Jul 18, 2023):

@jsidewhite just found a newer, wackier version of this repro:

Open a terminal window
Zoom the font size with the mouse wheel
wt -w -1 to open a new terminal window (of the same flavor) (defterm handoff works too)
BOOM, font size resets.

now why does that reload the settings?

@zadjii-msft commented on GitHub (Jul 18, 2023): @jsidewhite just found a newer, wackier version of this repro: * Open a terminal window * Zoom the font size with the mouse wheel * `wt -w -1` to open a new terminal window (of the same flavor) (defterm handoff works too) * BOOM, font size resets. now why does _that_ reload the settings?

claunia commented

@globalistas commented on GitHub (Nov 26, 2025):

Hilarious that this is still not fixed.

@globalistas commented on GitHub (Nov 26, 2025): Hilarious that this is still not fixed.

claunia commented