Overcolorization
andreyor.st
Tree-sitter became more widespread and Emacs took notice and included a bunch of -ts-mode as alternatives to -mode into the core. This is good news and a welcome change, but I have some concerns about the approach. When I first saw the Tree-sitter talk by Max Brunsfeld I was concerned that the language highlighting “fix” they’re talking about is too much.
  • lrochfort@alien.topBEnglish
    1·
    11 months ago

    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?

  • mickeyp@alien.topBEnglish
    1·
    11 months ago

    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.

    • hvis@alien.topBEnglish
      1·
      11 months ago

      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.topBEnglish
        1·
        11 months ago

        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.topBEnglish
          1·
          11 months ago

          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.topBEnglish
            1·
            11 months ago

            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.

  • grimscythe_@alien.topBEnglish
    1·
    11 months ago

    It’s a good opinion. However, colors work magic for reading code for me, so I guess it depends on the person.

    • oantolin@alien.topBEnglish
      1·
      11 months ago

      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.

    • 0xMii@alien.topBEnglish
      1·
      11 months ago

      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.

  • discursive_moth@alien.topBEnglish
    1·
    11 months ago

    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.

  • Starlight100@alien.topBEnglish
    1·
    11 months ago

    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))))
  • domsch1988@alien.topBEnglish
    1·
    11 months ago

    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.

  • github-alphapapa@alien.topBEnglish
    1·
    11 months ago

    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.

  • FrozenOnPluto@alien.topBEnglish
    1·
    11 months ago

    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?

    • hvis@alien.topBEnglish
      1·
      11 months ago

      Have you tried to use the same binding? python-ts-mode should have the same default set as python-mode due of how python-ts-mode-map is defined.

      To see all available bindings, type C-h f python-ts-mode RET. You’re probably thinking of C-c < and C-c >.

      • FrozenOnPluto@alien.topBEnglish
        1·
        11 months ago

        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!

        • hvis@alien.topBEnglish
          1·
          11 months ago

          These two bindings work for me. Does C-h f python-ts-mode RET show them in the list?