zyedidia
Color scheme issue
Environment
-
OS: Debian (bookworm)
-
Micro version: 2.0.13
-
Micro commit: 68d88b57
Issue
Taken steps
-
created a
colorschemesfolder inside of micro configuration folder -
created a colorscheme json file
Expected result
Apply of the colorscheme
Actual result
Error message:
The colorscheme is invalid
even if the .json file syntax is correct
- created a colorscheme json file [...] even if the .json file syntax is correct
micro's color schemes aren't any json files. They are called [NAME].micro.
See colors.md and colorschemes.
I have had a colorscheme working for a long time, recently broken. It is in a folder in .../micro/plug/colors/colorscheme-16.micro. When I launch micro, it yells at me "colorscheme-16 is not a valid colorscheme". When I open micro and press ctrl-e, set colorscheme colorscheme-16, it works properly for that instance. When I close micro and open again, the same issue arises.
I was able to reproduce the issue by having a plugin set up like this:
-- ~/.config/micro/plug/asd/asd.lua
local config = import("micro/config")
function preinit()
config.AddRuntimeFile("asd", config.RTColorscheme, "asd.micro")
end
# ~/.config/micro/plug/asd/asd.micro
color-link cursor-line "#FF00FF"
It seems that the issue is caused by micro attempting to load colorschemes before the plugin's preinit function runs to initialize the runtime files. I'm not sure if loading a colorscheme to use on startup from plugin ever worked: I tried out release versions v2.0.10-v2.0.14 and got the same asd is not a valid colorscheme error in all of them. Switching to the colorscheme after startup works as expected.
@mrvruj I have had a colorscheme working for a long time, recently broken. It is in a folder in .../micro/plug/colors/colorscheme-16.micro. When I launch micro, it yells at me "colorscheme-16 is not a valid colorscheme". When I open micro and press ctrl-e, set colorscheme colorscheme-16, it works properly for that instance. When I close micro and open again, the same issue arises.
For now you can get around this by placing the colorscheme file directly in ~/.config/micro/colorschemes/colorscheme-16.micro instead of loading it from a plugin.
It seems that the issue is caused by micro attempting to load colorschemes before the plugin's
preinitfunction runs to initialize the runtime files. I'm not sure if loading a colorscheme to use on startup from plugin ever worked: I tried out release versions v2.0.10-v2.0.14 and got the sameasd is not a valid colorschemeerror in all of them. Switching to the colorscheme after startup works as expected.
Yes, you're right, since the order of...
https://github.com/zyedidia/micro/blob/5428b3fda2457da08ca10e27a7b6470d7692c474/cmd/micro/micro.go#L322-L330
...definitely affects this behavior, but it's just half of the truth, because we validate every option already in the moment we parse the settings (https://github.com/zyedidia/micro/commit/4663927098334ae513a2b1d5bfa121905d034167) to be sure to work with fully valid settings and in the moment of validating the colorscheme settings we're still far away of adding the scheme via the plugin.
So someone could indeed call it a regression, but this scenario is then hard to fix due to circle dependencies...at least at first sight.
For now you can get around this by placing the colorscheme file directly in
~/.config/micro/colorschemes/colorscheme-16.microinstead of loading it from a plugin.
Yes, I think this is and should be the common approach to load colorschemes.
Doing this via plugins doesn't work right now (any longer).
I just want to say that this appears as a regression in some existing popular color schemes, which were already loading via plugins, such as https://github.com/KiranWells/micro-nord-tc-colors. With this change, it seems to become impossible to distribute color schemes as plugins now?
Can I also make a recommendation to disable the error/warning on startup entirely?
The color scheme is set in settings.json, which I store in my dotfiles repo that I pull down on any new machine(s) I'm working on. I imagine this is a common workflow. I gitignore plugins, because those are separately versioned and may differ per workflow. So when pulling down my config on a new machine, I'm hit with an error on every startup, until I install the associated color scheme / plugin.
On the other hand, if a color scheme is failing to load or is not installed, it should be readily apparent to the user as soon as they see the editor. The warning on startup is not actionable. It's just a nag. Nags are categorically not good UX design.
With this change, it seems to become impossible to distribute color schemes as plugins now?
Yes, but due to the design of micro it was never the best idea to mix them up together...it over-complicates a lot of things now.
Can I also make a recommendation to disable the error/warning on startup entirely?
I don't think that it's a wise choice to "ignore" some kind of inconsistency in the config.
The color scheme is set in settings.json, which I store in my dotfiles repo [...] pulling down my config on a new machine, I'm hit with an error on every startup, until I install the associated color scheme / plugin.
Yep, that is the current situation. But there is at least one way to bypass this with your dotfiles too. Why don't you maintain your own .config/micro/colorschemes/ folder in your dotfiles repository, where you store the colorschemes the settings of micro pointing to?
On the other hand, if a color scheme is failing to load or is not installed, it should be readily apparent to the user as soon as they see the editor.
Try to imagine some very simple colorschemes where only a few details should be highlighted, which could be overseen at the first sight.
We can try to handle this "regression", but I find it difficult to prioritize.
@dmaluka:
What's your opinion about this? Seems we've unintentionally increased the plugin vs colorscheme mess.
Try to imagine some very simple colorschemes where only a few details should be highlighted, which could be overseen at the first sight.
But a stop-the-world style interruption at startup feels like a drastic overstep for a pretty niche case. Why doesn't this display as, say, a warning in the gutter after startup? The worst case being solved for here (a color scheme failed to load) is pretty benign, versus the jarring experience of the entire editor stopping in its tracks. It fails the principle of least surprise.
I just want to say that this appears as a regression in some existing popular color schemes, which were already loading via plugins, such as https://github.com/KiranWells/micro-nord-tc-colors.
Hmm, this plugin calls config.AddRuntimeFile() from its top-level code, not from init() or preinit() callbacks. Very smart (no). I believe this way of using micro functions from lua was never guaranteed to work, never documented, it works by chance (AddRuntimeFile() happens to be implemented in such a way that it doesn't touch any data structures that are initialized after loading plugins). However, this explains the miracle: as @Andriamanitra correctly noticed, loading colorschemes via plugins at startup in a correct way (i.e. from init() or preinit()) never really used to work, however loading colorschemes via this plugin with this trick used to work until 2.0.14.
I wonder how many other plugins use this trick.
...Actually I've just found out that this trick is not something the plugin author came up with. This trick was suggested by @zyedidia: https://github.com/KiranWells/micro-nord-tc-colors/issues/2#issuecomment-748656296
More and more interesting.
BTW even before 2.0.14 it wasn't fully working: loading colorscheme specified in settings.json worked, however loading colorscheme specified in micro command line (micro -colorscheme nord-16 foo.txt) didn't. (Whereas colorschemes loaded normally from ~/.config/micro/colorschemes, not via plugins, worked and still work successfully in both cases.)
On the other hand, if a color scheme is failing to load or is not installed, it should be readily apparent to the user as soon as they see the editor.
No, it is not apparent to the user why the colorscheme was not applied. foo is not a valid colorscheme at least indicates that micro has successfully read the foo setting from settings.json, before it failed to apply this setting.
But a stop-the-world style interruption at startup feels like a drastic overstep for a pretty niche case. Why doesn't this display as, say, a warning in the gutter after startup?
There may be multiple configuration errors at startup. With a "stop-the-world interruption" we can report them all to the user, one by one, whereas with a warning in the gutter we would only be able to show one of them.
...Let's think how to address the root issue (non-working colorschemes loading via plugins at startup, in particular with existing plugins), then we won't need to think how to hide its consequences.
I think that all micro documentation should be included to each micro release instead beeing avaliable only online.
Besides of above, your don't address setting colors for specific languages (for example: python, perl, etc.) 😜
I think that all micro documentation should be included to each micro release instead beeing avaliable only online.
It isn't just available online only as mentioned here & here:
> help [USE_TAB_TAB_HERE]
By tabbing after > help you will receive the available list of help pages. When you've the desired entry press Enter.
The documentation is built into the binary too...as many other stuff. :wink:
I’m a new micro user and ran into this exact issue. I installed a colorscheme plugin, used set colorscheme nord-tc, and it worked. But when I restarted micro, it said nord-tc is not a valid colorscheme, even though running the same command manually works fine.
That was very confusing. From a user's perspective, the colorscheme clearly exists and works, but somehow micro can't see it during startup.
After reading through this thread, I understand the technical reason: micro validates the colorscheme setting before plugins are initialized. But the fact remains that this used to work. Even if it was never officially supported, many users relied on it, and existing themes and setups were built around it.
Breaking that behavior without warning or a migration path effectively breaks user setups. It interrupts workflows based on dotfiles and plugin-distributed themes, and the error message doesn’t explain what’s actually wrong.
At the very least, micro should delay validation until after plugin initialization, or provide a way for plugins to register runtime files early enough to be picked up during config parsing. Otherwise this becomes a silent regression that damages user trust and breaks working setups with no clear reason.
But the fact remains that this used to work.
I might have "worked" in this one particular scenario, but as mentioned by @dmaluka it failed in others as well... Maybe we find a solution to support colorschemes provided by plugins, but there is no guarantee that this will work without further plugin modifications. Currently this is no top/major issue and therefore most probably not addressed in the near future.
In case it is or gets important for you then please feel free to contribute a PR to address this.
Objectively this is a regression, so it would be better to fix it (which is unfortunate). Back when we discovered it, I was thinking how to address it with some ugly (but simple) hack that would make that hacky colorscheme plugin approach work again, and at the same time not break options validation or any other micro's functionality. E.g. treat the colorscheme option as a special case, or something like that. I hadn't come up with any particular hack, but IIRC I wasn't thinking really hard about it. Since then, we happily forgot about this regression.
Right now I don't have much time to think about it either.
Anyone is welcome to suggest any solution.
In the meantime the workaround is obvious: just use the needed colorscheme file from the plugin, e.g. https://github.com/KiranWells/micro-nord-tc-colors/blob/main/colorschemes/nord-tc.micro, by adding it to your ~/.config/micro/colorschemes. (Personally I've always found the idea of distributing colorschemes as plugins somewhat dumb.)
Ok, I've implemented https://github.com/zyedidia/micro/pull/3761 which fixes the regression (i.e. makes https://github.com/KiranWells/micro-nord-tc-col and other colorscheme plugins work again), plus it fixes the original issue (i.e. makes it possible for plugins to add colorschemes in a correct way, by calling config.AddRuntimeFile() from init() or preinit(), instead of using the above fragile hack with calling it from the top-level Lua code).
To be precise, not all problems with colorscheme plugins are fixed: at startup the colorscheme is loaded successfully, but after the reload command it is not. But the reason for that is precisely that plugins are using the above hack. So if https://github.com/KiranWells/micro-nord-tc-col and other plugin get updated to properly do that in init() or preinit() instead, it will fix the problem with reload as well.
(Although to be even more precise, this reload problem is also a regression: I see in 2.0.13 this problem was not observed. I haven't check why exactly, but I bet it is thanks to another bug we fixed in 2.0.14: #3062)
Hey. May I propose to change that the color schemes would be put into the "colorschemes" sub-folder of the folder with the micro, instead of creating recursive and duplicate copies of them in a sub-folder inside of the user's home directory?
This would prevent:
- unessecary duplication of the files
- make the updates easier, since everything would be in one folder and it's sub-folders
- prevent many possible issues of micro's files beeing in different places of hard drive
May I propose to change that the color schemes would be put into the "colorschemes" sub-folder of the folder with the micro, instead of creating recursive and duplicate copies of them in a sub-folder inside of the user's home directory?
But this is already the default approach of micro to have them all included in the colorschemes folder (see colors.md#creating-a-colorscheme)?!
It is just the approach to provide them within plugins, which causes problems (till #3761 is merged).
May I propose to change that the color schemes would be put into the "colorschemes" sub-folder of the folder with the micro, instead of creating recursive and duplicate copies of them in a sub-folder inside of the user's home directory?
But this is already the default approach of
microto have them all included in the colorschemes folder (see colors.md#creating-a-colorscheme)?! It is just the approach to provide them within plugins, which causes problems (till #3761 is merged).
Hopefully you all find a way to fix it in the near time ;-) 👍🏼