Poliorcetics
Poliorcetics
@the-mikedavis I didn't add the theme checking but having a single source and always up to date source of truth for theme keys should make it much easier to know...
> I preferred seeing keys as "scope.scope.scope" rather than "ScopeScopeScope" - the fallback behavior was more intuitive. Is there a different way of approaching this, maybe by using a macro...
> We could make use of namespacing. I can try generating something like `ui::Menu`, and `Ui` constants yes, with the enum as backing type, good idea. I'll see what I...
> We could make use of namespacing. Well it's very hard in `macro_rules` and I'm not willing to introduce such a proc macro for just this, the complexity and compile...
TODO for self: - Fix build - Rework from [this comment](https://github.com/helix-editor/helix/pull/3690#issuecomment-1250057151)
I moved the names to `Ui_Linenr_Selected` format, to make it easier to read and rebased on most recent master
I don't think CI failures are related to my changes
What do I have to do for this to move forward ? IMO it would greatly improve documentation for theme keys, and avoid allocating strings in several places
The documentation benefits to know what is used in themes and what is not are nice and not to be dismissed. For example, this PR surfaces several duplications between `sshconfig`...
Also, for Rust, `unsafe` highlighting is nice in VSCode and what I miss the most in helix