-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal: Base17 style system #56
Comments
This goes without saying that the intricacies a scheme's YAML format does not belong in the builder spec... if we hope to support multiple style systems:
They do not all need not use the exactly same data layout... perhaps some have nested structures, perhaps some do not. Nor should we be "stuck" with the limitations of Base16 forever (one layer of keys, 16 of them) if that's not conducive to any particular style system. More ambitious style systems like Base9 might include entirely different types of data than empty slots and hex colors. If a builder is going to support a style system that style system only needs to publish a canonical, versioned style guide - and then the builder needs to say that it supports that system. Here is the output from node builder currently when you ask it for version.
|
I started looking into this as I wanted a quick source of 'standard' theme colors, that could be ported to a specific app (the tridactyl browser). After some more reading around, I'm somewhat surprised that there isn't already a standard simple text format for programmer themes. The closest seems to be tmTheme which seems to just be a plist generated my a Mac GUI app. Every advanced editor will have it own subtleties and options so editor specific color themes will always be necessary but it feels like there's a gap for a combination of Base16 and tmTheme to simply capture "famous" color schemes in a slightly more standard way, which this Base17 proposal sounds very close to. Building on (either reuse or mapping to) the tmTheme community built naming scheme would probably allow very fast bootstrapping of the new format https://www.sublimetext.com/docs/scope_naming.html#color_schemes This might also allow converting to the legacy tmTheme format for immediate use, with the idea that people might directly support Base17 in the way they use Base16 in the future if the idea catches on. |
If you're interested in the finer details you may want to see #24 and #11. I do like the TextMate scoping stuff... I worry that it might be a bit "too much" though... I specifically worry about the complexities of getting into nested scopes... I'm open to persuasive arguments. Obviously want to cover the syntax space pretty well though - so even if we go with something simpler it should definitely be mapable into the TM namespace, so you could definitely generate tmThemes - I think we already have a template for that even. |
I've create a new repo for what I'm calling the Base17 style guide: https://github.com/base16-project/base17
Ref: #11
I'd love feedback, the spec itself can be found under
style_guide.md
.In my opinion this is how we move forward - now that Chris has reasserted his ownership of Base16: by creating our own style systems - that are wholly our own and we can evolve and do with them as we like.
base16-schemes
tobase17-schemes
and then we can begin to evolve the base17 style system (that we own) - or introduce additional style systems (Ansi16, etc)I think getting our tooling to accept and work with the fact that there are real and divergent (the input files won't all look the same) style systems is the first step to making all of this more concrete.
Originally posted by @joshgoebel in #11 (comment)
The text was updated successfully, but these errors were encountered: