It’s very personal.
I like monochrome with very mild weight differences. I find all the colours distracting; from my perspective we don’t colour code regular prose, so why code?
The problem is monochromacity. The font lock rules in a lot of the TS modes are… not always thought through. Ramp up python-ts-mode’s font lock level to the maximum and most of everything is dyed the same colour. It’s frustrating and I have had to muck around with treesit-font-lock-feature-list to selectively unpick the chaff from the grist. And it’s not exactly easy changing it either: if you’re new to elisp, or not fluent in the extremely awkward interface for changing this stuff, you’ll have to look up how someone else has done it.
It’s not even customizable, so you can’t just click around and change it either.
The font lock rules in a lot of the TS modes are… not always thought through. Ramp up python-ts-mode’s font lock level to the maximum and most of everything is dyed the same colour.
And then on the other side, people come asking why even when TS is used, highlighting is not “up to par” with VS Code and etc. Then hear about treesit-font-lock-level, ramp it up to the max, and apparently live happily after.
That’s a misinterpretation of my argument. I said monochromacity: that at the highest level, many disparate node types are font locked with the same face. Try it in Python. Everything is the same shade of whatever your variable name face is.
So your complaint is about the non-default behavior? The level 3 was chosen as default explicitly to avoid the abundance of color where it’s not really needed.
I said monochromacity: that at the highest level, many disparate node types are font locked with the same face. Try it in Python. Everything is the same shade of whatever your variable name face is.
I don’t see that “everything is the same shade”, even with level 4. There are problems - like the variable matches in particular (which is not useful IMO, but should at least use a different face). The rest use different faces, but since most of those faces are new, it’s up to the theme authors to differentiate them.
Here’s a patch fixing the one problem I found (try it), and below is a screenshot with this patch applied along with the new faces customized to be distinct.
diff --git a/lisp/progmodes/python.el b/lisp/progmodes/python.el
index d3cb5a77e22..9f9344e0eb4 100644
--- a/lisp/progmodes/python.el
+++ b/lisp/progmodes/python.el
@@ -1235,7 +1235,7 @@ python--treesit-fontify-variable
(when (python--treesit-variable-p node)
(treesit-fontify-with-override
(treesit-node-start node) (treesit-node-end node)
- 'font-lock-variable-name-face override start end)))
+ 'font-lock-variable-use-face override start end)))
;;; Indentation
It’s a good opinion. However, colors work magic for reading code for me, so I guess it depends on the person.
When you say “however, colors work magic for reading code for me”, do you mean having most text in the same color, say purple, or do you mean having a variety of colors? Because the article specifically complains that “everything is purple” in elixir-ts-mode instead of having a wider variety of color.
I think this is a problem for theme makers. Having the option to colorize more tokens is great, but I’m sure we’ll get themes that approach colorizing with more restraint too.
These might help:
