this post was submitted on 22 Nov 2023
0 points (50.0% liked)

Emacs

313 readers
2 users here now

A community for the timeless and infinitely powerful editor. Want to see what Emacs is capable of?!

Get Emacs

Rules

  1. Posts should be emacs related
  2. Be kind please
  3. Yes, we already know: Google results for "emacs" and "vi" link to each other. We good.

Emacs Resources

Emacs Tutorials

Useful Emacs configuration files and distributions

Quick pain-saver tip

founded 1 year ago
MODERATORS
rglullis
raphael
0
Overcolorization ("Everything is purple") (andreyor.st)
submitted 1 year ago by unhammer@alien.top to c/emacs
21 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[–] hvis@alien.top 1 points 1 year ago (1 children)

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.

[–] mickeyp@alien.top 1 points 1 year ago (1 children)

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.

[–] hvis@alien.top 1 points 1 year ago (1 children)

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

https://imgur.com/a/iifAmcd

[–] mickeyp@alien.top 1 points 1 year ago (1 children)

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.

That's not what I wrote.

I don't see that "everything is the same shade", even with level 4. There are problems - like the variable matcher in particular (which is not useful IMO, but should at least use a different face).

The variable matcher, indeed, is the one I was talking about...

Here's a patch fixing the one problem I found

I'm glad we're on the same page.

[–] hvis@alien.top 1 points 1 year ago

You're welcome.