Sublime Forum

Reverting the python syntax highlighting?

#1

I think 4166 introduced a new python syntax highlighter that does some things I am not used to and therefore dont like. I don’t want to spend time right now getting used to the new highlighting. Is there any way to revert this locally? Maybe building a package with the old syntax definition that I could use to overwrite the current one. If so where would I find the old syntax definition?

Thanks

0 Likes
#2

Built-in packages are developed here: https://github.com/sublimehq/Packages. What specific changes are you unhappy about?

0 Likes
#3

Thanks for the info I will check that out! I am guessing it will have what I am looking for.
I have noticed two things so far.

First from typing import List, Dict stylizes List and Dict differently then all other imports. I am guessing this is done because packages within typing are builtin-like, but when styling only applies to specific classes and not all classes it seems silly.

And second from somepackage import SomeClass # type:ignore styles type and ignore a bright contrasting color. I am not used to comments being a color that the eyes are drawn to, and would prefer if contents of comments were never similar looking to code.

Again, I dont actually know if these changes are good or bad in the long term, I would need to get used to them first before being able to make that judgement. I am just looking to push back dealing with getting used to it to a later time.

0 Likes
#4

I would suggest you modify your color scheme. Reverting scope changes is not impossible but unlikely.

Because your issue is coloring, which is a personal taste defined in color scheme, but not scoping defined in syntax definition.

I mean

  • Is List built-in? Yes, without a doubt.
  • How should built-ins be colored? Every one has his/her own answer.

As for your initial question, using arbitrary version of Packages:

You just copy the Python folder of the commit you are interested in from GitHub into the Packages/ folder of your ST. The issue of doing so is that, it effectively rejects all future update of the Python package.

2 Likes
#5

I wouldn’t recommend reverting any default package with older ones as various 3rd-party packages depend on them (extend them). Using out-dated default packages not complying with ST build number are a likely cause for those 3rd-party packages to break.

A question of taste, whether built-ins are to be tinted differently. Python syntax extended patterns to add those from typing module to the list of built-ins, for those who would like to tint them with dedicated colors. Those can be addressed by…

{
	"rules":
	[
        {
            "scope": "support.class",
            "foreground": "..."
        },
	]
}

The following rules may be a starting point to tweak type annotation tinting via UI: Customize Color Scheme.

{
	"rules":
	[
		// Python type annotations

		{
			"name": "Annotation Background",
			"scope": "meta.type",
			"background": "color(var(textcolor) blend(var(background) 4%))",
		},

		{
			"name": "Python Type Annotations: Types",
			"scope": "meta.type & (meta.generic-name, support.class, support.type, storage)",
			"foreground": "color(var(grey) blend(var(blue) 70%))",
		},

		{
			"name": "Python Type Annotations: Constants",
			"scope": "meta.type & (constant.language, constant.other, string)",
			"foreground": "color(var(grey) blend(var(orange) 70%))",
		},
	]
}
3 Likes
#6

Thanks for this info. This is indeed personal taste and I think I agree with everything @jfcherng says. I will look into changing the color scheme too for the reasons @deathaxe mentions. I have learned much about the syntax highlighter from this thread. It does seem like changing the color scheme is the right choice here. My only remaining concern with this approach is accidentally changing how a different language looks because I change some styling for this one. If anyone knows, can I assume just appending the language name to the end of the scope is sufficient or will it be more case-by-case? Otherwise I will just experimentally validate this.

0 Likes
#7

You can always write language specific highlighting rules by including a languages main scope (e.g.: source.python meta.type).

0 Likes