Prettier (+/- colors for semantics) and more readable codeblocks

[aartaka]

Prettier (+/- colors for semantics) and more readable codeblocks

[aartaka]

Here's the same code block in both themes. Legend:

• Primary link (define-configuration): macro, special syntax, referenciable and inspectable inside Nyxt, hard to change.
• Regular link (make-keymap): function, class, or any other "normal" program entity. Referenciable, inspectable, easy to change.
• Action color, no link (let): special built-in form. Not inspectable, unchangeable.

(Wow, I haven't ran latest Nyxt for some time, light theme codeblock color looks SLEEEEEK 🤩)

[aartaka]

aartaka I know we talked about accommodating other languages in the structure-

Actually, our 4 semantic code groups (see comment above) apply to most other programming languages, and they might be a nice minimalist theme for them. I mean, when we're done with code colors, I might even use the idea in my Emacs coding setup 😂

[aadcg]

I think that the only important aspect is that Nyxt's default themes need to be made properly. Custom themes are the the author's responsibility and they may not follow the contrast directives we follow.

---

As a sidenote, I think we should not reference "Modus themes" in our sources. Generally speaking, any reference to external projects is not desirable (including emacs, vi, etc). Nyxt is not an imitation project and should not stay in the shadow of others. It's not VI that invented modal editing. And it's not the Modus themes that came up with the idea of ensuring contrast ratios for readability.

[aartaka]

I think that the only important aspect is that Nyxt's default themes need to be made properly. Custom themes are the the author's responsibility and they may not follow the contrast directives we follow.

No. The whole point of theming is that we provide a set of APIs conforming to which one can make a pretty theme equal to built-in ones. Yes, if someone injects custom CSS extending the theme beyond our APIs—it's their own problem. But all the otherwise, all themes should be born equal.

And note that it's not (only) about contrast anymore: contrast is ensured automatically. It's about semantics of themes and making themes understandable and reproducible by anyone.

Generally speaking, any reference to external projects is not desirable (including emacs, vi, etc).

A counter-example: we mention Google, Pypi, DOI, DuckDuckGo already. Quite explicitly, in the manual. How is Modus theme different? Note that Solarized (!) is a project too. And Darkula. And Monokai. Most themes are separate external projects, so you can't make an omelette without breaking eggs make theming without mentioning themes.

And it's not the Modus themes that came up with the idea of ensuring contrast ratios for readability.

I'm not mentioning that anywhere.

[aartaka]

And then, this issue also influences built-in themes, and will likely influence themes that @lansingthomas is baking. So we have to address it universally, whatever the support status for external themes.

[aadcg]

Most themes are separate external projects, so you can't make an omelette without breaking eggs make theming without mentioning themes.

A theme can be made without mentioning others. Just like Coca-cola doesn't mention Pepsi, even though both are colas.

[lansingthomas]

Would more text colors help?

Something like:
text: code-alt
text: code-symbol
text: code-extra
text: code-fun
text: code-parens

It is kind of cool to be able to set your own code colors

[aartaka]

Would more text colors help? Something like: text: code-alt text: code-symbol text: code-extra text: code-fun text: code-parens

Sounds like text+ and text- to me. Maybe use these (+/-) text variations instead? Requires that codeblock text is in sync with the background one, though...

[lansingthomas]

I don't think I understand the proposal.

What parts am I missing?

Let me try to list the elements of a code block in default state in Nyxt, and @aartaka maybe you can fill in the missing parts.

codeblock text;

• text color {text from the text colors palette}
• text size and style {from the typography guideline}
• background color {codeblock from surface colors palette}
• background size and shape {we have not established an explicit convention for this yet}
• ????? help

[lansingthomas]

The more I reflect on this the more I want to try some more colors for the built in operators and the symbols. Our palette is SOOOO minimal already.

@aartaka can you send me a nice code example snippet with all the elements?

[lansingthomas]

record of a conversation:

Artyom and Tom spoke about code block styling, and considered three options moving forward to help differentiate typographic code elements like special forms, code macros, ... perhaps even things like functions, conditionals, objects from other languages.

Proposal 1 - rely on text decoration like bolding and underlining

• works great for some themes, a good option in some cases.
• insufficient for certain themes {low saturation, bright text etc.}

Proposal 2 - use existing surface colors as text colors in these special cases

• we experimented with the color combinations that appeared promising and found the combinations to be poor. {contrast test failures, poor readability, crappy aesthetics}
• this method also feels inconsistent... using surface colors for text... YES it happens in some other places like buttons in certain states... we risk some really bad looking code editing situations.

Proposal 3 -- add some more text-colors

• the downside: more objects to manage.
• the upside: more user freedom when creating custom themes (or editing existing themes)
• more colooooors! 🍎🍏💙💚💛💜📗📘

We settled on proposal 3.
experiments are ongoing.

[lansingthomas]

Would these styling groups be acceptable?
(to add to the text color category -- which currently has: text, text+, text-, and constrast-text

1. literals (things that eval to themselves)
2. macros (incl. functions)
3. special forms
4. keyword-arguments (symbols in the keyword package)
5. comments (;)

[lansingthomas]

@aartaka I know we talked about accommodating other languages in the structure-

• I am deciding NOT to worry about this at the moment, the simplest system I could find that does this uses (23 variables) x (10 modifiers) ... which is well beyond our scope for now. ^^

[aartaka]

1. literals (things that eval to themselves)

Yes.

2. macros (incl. functions)special forms

Not sure I get the idea, but I'm inclined to have macros+specials as one group, and functions as another.

3. keyword arguments (symbols in the keyword package)

Might (should?) be merged with literals (although my Emacs theme colors them differently. Fancy and useless 😃)

4. ;comments

Yes. So , to summarize my idea, it's four groups: (1) regular code/symbols/functions/variables/etc. (you haven't mentioned this one, is it implied? I decided to include it for completeness); (2) literals+keywords (3) macros+specials (4) comments.

(23 variables) x (10 modifiers)

Even thinking about that fills me with horror.

[lansingthomas]

Even thinking about that fills me with horror.

yes run! Flee while you can.

(1) regular code/symbols/functions/variables/etc. (you haven't mentioned this one, is it implied?...)

yes, text covers this for now

[lansingthomas]

I think having literals and keyword-arguments as one item makes sense

[lansingthomas]

I keep running up against the limit of my knowledge here.

@jmercouris
Can you help us group this dumb word salad into a coherent structure?