- cross-posted to:
- emacs@communick.news
- cross-posted to:
- emacs@communick.news
You must log in or register to comment.
It might seem like a subtle improvement to you but I really think it actually achieves the goal of making it so that you can kind of get the structure of the code just from glancing at the colors.
Structure, from colors. I don’t know, I have never tried to infer structure from colors in the code.
This is what prism.el provides: color reflects logical depth, which signifies the primary aspect of structure. IMHO it is generally more useful than making function names stand out (their position makes them stand out anyway), variable declarations a certain color (though helpful, I don’t need to see that constantly), etc. A well-written piece of code communicates a lot by its shape, which logical colorization helps to reveal.
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-listto 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
variablematches 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))) ;;; IndentationSo 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.
You’re welcome.
It’s a good opinion. However, colors work magic for reading code for me, so I guess it depends on the person.
It definitely does. While I like some color (monochrome themes aren’t my bag), a lot of themes are too much for me and distract me more than they help me. I’m definitely on the “less is more” end of the spectrum.
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:
I love the new treesit faces. But agree when literally everything has an attention drawing color, then nothing does.
What works for me is to disable special colors for variable use, only var declartion.
(custom-theme-set-faces (or (car custom-enabled-themes) 'user) ; current theme ;; attention drawing color for var definitions. `(font-lock-variable-name-face ((t (:foreground "cyan" :background "black")))) ;; normal color for var-use. To avoid color spagetti. (new treesit face) `(font-lock-variable-use-face ((t :inherit default))))Yeah, I’ve started to notice the same for me. I use neovim and emacs at work. Many files I open are now rainbow puke. I’m sure some people find it useful. I personally use an lsp and treesitter mostly for automatic indentation.
I’m thinking about making a color scheme which uses one color besides the main foreground and uses font weight and slant for highlighting in 90% of cases, limiting color to spare, relevant places. I’m tired of every string, number etc. being colorized. Just looks cluttered imho.
Regarding elixir-ts-mode in particular, as noted in https://debbugs.gnu.org/67246, its highlighting is currently being reworked.
Aside - is there any good docs about _using_ treesitter mode? Setting it up was covered in a few great notes and guides, and took only a couple minutes.
ex: python-mode has a keybinsd that shifts current line/region right or left a hop; super handy! I didnt’ see any obvious keybind for that in python-ts-mode … I expected to have a lot of like-for-like in the new mode, but I guess thats not quite right. Its not ‘a new python mode’, its ‘treesit modes’, so have to get used to presumably new keybinds for treesit-modes … and maybe they’re even consistent across languages (that’d be something!) … alas, I didn’t find out what that key was, so, sort of a shame.
Any handy list of keybinds that are super useful across the treesit modes?
Have you tried to use the same binding?
python-ts-modeshould have the same default set aspython-modedue of howpython-ts-mode-mapis defined.To see all available bindings, type
C-h f python-ts-mode RET. You’re probably thinking ofC-c <andC-c >.Many of the ‘defaut’ (in my head) bindings dont’ work in python-ts-mode (such as C-c >), but perhaps my config is blowing something up. Hmm … I’ll dig in more, thanks!
These two bindings work for me. Does
C-h f python-ts-mode RETshow them in the list?
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?