Italic theme variant

[re1]

Many color schemes (like Night Owl or Monokai Pro) use italics to style specific keywords. Not only does this look great for many fonts (especially Operator and Dank Mono) it also makes it easier to distinguish those keywords from similarly colored companions.

PS: Italics are actually the only reason I still use Monokai Pro over Nord.

[arcticicestudio]

Thanks for your contribution 👍

Nord makes use of italics for some elements all over different port projects (for consistency) and most important when it makes sense, e.g. for static variables / properties / class attributes to better differentiate from other „normal“ ones. Also static methods / functions as well as some builtin ones are used with italic font.

I know some of these new themes and font you refer to and I've to say (personally) I absolutely dislike the style and this suddenly appeared trend. Almost every second word is italic and uses this illegible old antique curlicue fonts. Before this everyone tried to create better monospaced fonts (like the awesome Source Code Pro and Hack font families) and now it's like the exact opposite: Make the code look like a book from the ancient Romans.
Again, this is my personal opinion, but in some aspects this is reflected in Nord too 😉

I know that VS Code provides a way to ship „sub-themes“ with one bundle so if this a features many users like to see we can implement a „italic version“ so users can select which they'd like to use (while the actual one stays the default). I'm not convinced yet since I don't know what would make sense to use italic fonts for other than the current ones (like all keywords and language specific elements, only user-defined ones, …).
Maybe some more ideas how to implement would be nice so a prototype can be created.

[WTFox]

Bumping this in favor of using italics in comments for fancy fonts.

[ianrohde]

@WTFox, you can set comments to italic in your local VSCode settings with:

"editor.tokenColorCustomizations": { "textMateRules": [ { "scope": "comment", "settings": { "fontStyle": "italic" } } ] },

[bashfulrobot]

Just to further, I had done the following to mimic another theme I used prior to this one. It is all personal preference.

"editor.tokenColorCustomizations": {
        "textMateRules": [
            {
                "scope": "comment",
                "settings": {
                    "fontStyle": "italic"
                }
            },
            {
                "scope": "keyword",
                "settings": {
                    "fontStyle": "italic"
                }
            },
            {
                "scope": "language",
                "settings": {
                    "fontStyle": "italic"
                }
            },
            {
                "scope": "keyword",
                "settings": {
                    "fontStyle": "italic"
                }
            },
            {
                "scope": "string",
                "settings": {
                    "fontStyle": "italic"
                }
            },
            {
                "scope": "storage",
                "settings": {
                    "fontStyle": "italic"
                }
            },
            {
                "scope": "constant",
                "settings": {
                    "fontStyle": "italic"
                }
            }
        ]
    }

[arcticicestudio]

Thanks @ianrohde and @bashfulrobot, I guess this helps users that are currently looking for a “italic spiced” variant. Unfortunately, I'm still not convinced to bundle an italic variant for the extension. Personally I don't see any point in using italic styles for almost all language tokens making it harder to read and distinguish from actual “special“ elements like a local variable vs. a global/static variable.

I think a possible solution would be to add a section to the FAQ and troubleshooting guide (currently work in progress) in the docs that provides tips how to customize the theme for more italic styles, e.g. for users who switched from themes like Night Owl that makes heavy use of this style. It could link to some GitHub Gists of user-created styles as well as to the already existing guide about theme syntax customization that can then be referred to in order to guide users to the process of adding these styles.

[arcticicestudio]

Oh, one reason just came to my mind that could be a good argument for an additional bundled italic variant:

👁️‍🗨️ Accessibility ♿

User that are affected by color blindness or limited vision skills, especially for colors, would benefit from it. Using a italic font style for syntax elements like language keywords and primitives (string, int, …) as well as language builtin types (struct, class, …) coming from the SDK/runtime would help to differentiate from user-created code like custom structs/classes or functions/methods.
I need to think about it again, maybe some input from actually affected users would be great so the variant could be developed together for the best possible optimization.

[bashfulrobot]

Accessibility it's an amazing point. I was reading an article on tabs vs spaces with context to accessibility... Just message me realise there are some other great reasons for various visual cues.

[imtbl]

Imo, italics can be very beneficial for visually scanning blocks of code if they are not overused, even for people without any visual impairments. E.g., I personally like them a lot for return statements and comments.

I also do agree that they can look weird in direct comparison to the regular font. I've used a patched version of Operator Mono with programming ligatures in the past, but have switched to Dank Mono a while ago because I find the italics in that font feel more coherent with the rest of the text (while still standing out enough to make them easily distinguishable).

On the topic of having a sub-theme, I'm not sure if that is really necessary and it could also lead to having a lot of sub-themes/variants quickly if you, e.g., decide to ship variants with different colors (e.g., a darker version) later.

Introducing yet another visual setting besides italics (I can't think of something specific right now, so let's call it x) would then cause something like this:

• Regular
• Regular (with italics)
• Regular (with x)
• Regular (with italics and x)
• Dark
• Dark (with italics)
• Dark (with x)
• Dark (with italics and x)

I think something like a useItalics setting might be more appropriate for this. And if that's not enough, people can always fine-tune it manually to their liking via editor.tokenColorCustomizations.textMateRules.

[jeanvcastro]

I use this settings:

"editor.tokenColorCustomizations": {
        "textMateRules": [
            {
                "scope": [
                    "comment",
                    "comment keyword",
                    "comment markup.underline.link",
                    "comment string",
                    "comment punctuation.definition",
                    "comment punctuation",
                    "comment text",
                    "entity.other.inherited-class",
                    "entity.other.attribute-name",
                    "entity.other.attribute-name.pseudo-class.css",
                    "entity.other.pseudo-class.css",
                    "entity.other.pseudo-element.css",
                    "invalid",
                    "markup.italic",
                    "markup.quote",
                    "source.sass variable.other",
                    "source.sass variable.sass",
                    "source.scss variable.other",
                    "source.scss variable.scss",
                    "source.scss variable.sass",
                    "source.css variable.other",
                    "source.css variable.scss",
                    "source.less variable.other",
                    "source.less variable.other.less",
                    "source.less variable.declaration.less",
                    "storage.type",
                    "storage.modifier",
                    "storage.type.modifier",
                    "support.type",
                    "entity.name.type.object.console",
                    "support.type.property-name",
                    "variable.parameter",
                    "parameters variable.function",
                    "variable.language",
                    "variable.parameter.function.language.special.self.python",
                    "variable.parameter.function.language.special.cls.python"
                ],
                "settings": {
                    "fontStyle": "italic"
                }
            },
            {
                "scope": "markup.bold",
                "settings": {
                    "fontStyle": "bold"
                }
            },
            {
                "scope": "markup.underline",
                "settings": {
                    "fontStyle": "underline"
                }
            },
        ]
    },
}

[svengreb]

Thank you for your patience! 🙏🏼
It‘s been a while since I had free time to focus more on Nord, and my open source projects in general, and invest time in this issue due to work-life balance.

I recently published the first “Northern Post — The state and roadmap of Nord“ announcement which includes all details about the plans and future of the Nord project, including the goal of catching up with the backlog. This issue is part of the backlog and therefore I want to triage and process it to get one step closer to a “clean state“. Read the announcement about reaching the “clean“ contribution triage state in Nord‘s discussions for more details about the goal.

Due to the scope of this issue of not being “purely technical“, or being related to the project‘s code at all, I‘ll convert it into a discussion for Nord‘s central community hub on GitHub. This way the repository is easier to maintain by separating conversations about the actual code while also making help requests, ideas and other contributions from users more visible and supportable by the community.