Skip to content
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

Open
joshgoebel opened this issue Jul 7, 2022 · 3 comments
Open

Proposal: Base17 style system #56

joshgoebel opened this issue Jul 7, 2022 · 3 comments
Assignees
Labels
enhancement New feature or request proposal An idea which may or may not be acted on
Milestone

Comments

@joshgoebel
Copy link
Contributor

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.

  • We leave the Base16 style spec alone - if our tools work with it (and I think they should) great, but we shouldn't be changing or evolving it under the "base16" auspice.
  • We create a new forwards compatible spec, Base17 - so allow us to evolve the system. All Base16 schemes are valid Base17 schemes - just base17 allows you to start doing more (better control of syntax highlighting, etc).
  • We rename base16-schemes to base17-schemes and then we can begin to evolve the base17 style system (that we own) - or introduce additional style systems (Ansi16, etc)
  • Existing base16 templates can compile base17 (with slightly lower fidelity) and new templates can fully process the new features of base17.

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)

@joshgoebel
Copy link
Contributor Author

joshgoebel commented Jul 7, 2022

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:

  • Base16 (largely set in stone already)
  • Base17
  • Base24
  • Ansi16
  • Base9 (maybe)

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.

base16-builder v1.1.0
  builder spec v0.10.1
  base16 style spec v0.2
  base24 style spec (5625d94)

@joshgoebel joshgoebel changed the title Proposal: Base17 Proposal: Base17 style system Jul 7, 2022
@joshgoebel joshgoebel added enhancement New feature or request discussion labels Jul 7, 2022
@joshgoebel joshgoebel self-assigned this Jul 7, 2022
@belak belak added proposal An idea which may or may not be acted on and removed discussion labels Jul 8, 2022
@joshgoebel joshgoebel added this to the Base17 milestone Jul 8, 2022
@joshgoebel joshgoebel pinned this issue Jul 9, 2022
@davidscotson
Copy link

davidscotson commented Jul 9, 2022

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.

@joshgoebel
Copy link
Contributor Author

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.

https://github.com/chriskempson/base16-textmate

@belak belak unpinned this issue Dec 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request proposal An idea which may or may not be acted on
Projects
None yet
Development

No branches or pull requests

3 participants