Sorry for the late update for the photos.

This is what you will see when you open keymap.

This is what you will see when you open the actions panel, and search for theme modes.

Tests are in the code, please feel free check them out.

@SomeoneToIgnore seems orchestrate fails due to the branch of this PR is too far behind, lemme rebase from main within today. 🙏

@SomeoneToIgnore just finished rebase, please activate the workflow again, thanks!

about the clippy and test check, may I know if the workflow has changed recently? since I run cargo clippy and no errors at all, and I found a separate clippy script in script directory.

The workflow had been reworked a few times during past 6 months, but the overall idea was the same: ./script/clippy to check the style + a step that runs the tests.

Seems that the PR needs to fix its tests first?
I see 2 new test are failing with some theme-related errors:

but not sure what to add on top of that.

The workflow had been reworked a few times during past 6 months, but the overall idea was the same: ./script/clippy to check the style + a step that runs the tests.

Seems that the PR needs to fix its tests first?

I see 2 new test are failing with some theme-related errors:

but not sure what to add on top of that.

thanks for the check out, working on that.

Overall, looking at the PR, I am not sure about the amount of actions to add: would it be better if we could have an action that toggles theme modes (first, if needed, switches into the mode that allows toggling first)?
If we go this way, it might also better be tested in editor_tests.rs instead of the current settings-related change?

The flow you suggested seems better, when in static, you only have option to switch to dynamic mode.

While in dynamic mode, you can choose system, light, dark, or switch back to static.

Does that sounds good?

Do we really need the "back to static" thing?
How other editors do that?

I would say this is completely new and not seen in other IDE/text editors.

I checked VSCode, Xcode, and Android Studio, they dont have a shortcut to manually switch between light, dark or system. The only have shortcut to open color theme selector, which is the same thing as theme selector in Zed.

"back to static" is prob like a edge-case handling for me. e.g. maybe the user just wants the single theme, instead of switching between light and dark or following the system, which changes themes when sunrise/sunset.

Side track

About Static and Dynamic Theme Mode, I am not sure if we really need that much level of customization.
When I walk through the flow of theme modes, I feel a bit nested(?)/clumsy(?) when I switch to dynamic mode.

The IDEs I checked on, they are mostly working with single theme selection box, plus a option to sync with OS, thats all.
I remember previous versions of VSCode (some years ago, I forget), do have the options similar to Zed right now, but eventually they changed back to theme selector, which you can only select 1 theme.

As my personal experience, I mainly just pick a theme I am familiar with e.g. material, one dark, xcode default dark, then I mostly wont touch that part anymore. While keeping light theme is also reasonable, mostly I would expect they are in pairs with the dark theme.

If possible, I would like to make themes into optional theme pairs, and replace dynamic mode with "sync with OS" option. But that's definitely not this PR. This PR just aims to provide more flexibility on switching themes

Lemme know what you think.

The workflow had been reworked a few times during past 6 months, but the overall idea was the same: ./script/clippy to check the style + a step that runs the tests.
Seems that the PR needs to fix its tests first?
I see 2 new test are failing with some theme-related errors:

but not sure what to add on top of that.

thanks for the check out, working on that.

small update:
Another potential problem is, when I try to run the test, rust crates and compile cache fill up my storage real quick lol.
I can just push the potential fix here, but I want to test locally to make sure things doing fine.

they dont have a shortcut to manually switch between light, dark or system. The only have shortcut to open color theme selector,

Maybe there's no shortcut, but there's definitely an action in VSCode:

And I suspect that's what people want, really, at least now in that discussion: no dynamic/static switch, just dark/bright theme switching.

I would start with that, but lack good context on the modes right now: presumably, we'll have to consider switching the mode once when toggling, but overall what we have to do is to toggle between dark/bright and persist that choice + have tests for all modes for this.

Maybe there's no shortcut, but there's definitely an action in VSCode:

ahhhh so it is in preferences, no wonder I cannot found it lol.

we have to do is to toggle between dark/bright and persist that choice + have tests for all modes for this.

But in order to adapt with the current appearance settings, system mode needs to be catered also(which means we cannot do the toggle just like VSCode). And this is the intention why I separate them into 3 independent actions and hotkeys.

But I 100% agree we should keep it simple.

Great, so this is the caveat I've missed, the system mode: to me, does not seem wrong to automatically convert such mode into something more suitable then (Static, it seems? not sure) and switch still.

This can be documented so people have less surprises and sure, should be tested, as all other modes' switching.

I am thinking, should we switch static to system in this PR, since my intention is to just extend the flexibility of switching themes using actions and shortcuts.

I can do it in a separate PR to swap static mode out I guess...?

From the user's perspective:

• there has to be an action that toggles between bright and dark, persistently
• ??? nothing else, right?

So, if we can add an action that gets us into this switching loop out of whatever related settings state + have it tested, we're good.
The rest is details interesting to know at the impl review time, no more (but no less).

you are correct, I got stuck into how to do things gracefully.

Lemme implement it these 2 days! Thanks.

I did some refactoring based on the discussion above:

• convert all the actions to become a single toggle between light and dark theme.
• when the user is in static mode, it will change to dynamic mode, the theme will filled up both light and dark theme (documented in themes.md)
• add default keymap for the toggle action

lol typo on markdown, lemme update that real quick

@SomeoneToIgnore I have updated the tests quite a bit, please review when you are free, thanks a lot.

about cx.theme() test, I might need to include a file_watcher in order to test it.
Since the technical flow of the whole action is:
toggle_theme_mode -> disk(update_settings_file) -> file watcher(watch_config_file) -> SettingStore -> cx.theme()

@SomeoneToIgnore Thank you too, I do learn a lot during a whole process.

And an extra wholehearted thanks to go through the structure of editor appearance with me, thus the patience to explain concepts and mindset.