Take a look at the python code above. Because the word filter is a builtin function it gets highlighted differently than the rest of the code. The problem is, none of the occurrences of the word here relate to the builtin function and it semantically should not be any different from any other decorator or callable.

I honestly think that this is a bug with the syntax highlighter (as it should be easy to discern between a built-in function call and a method from another class, but if I could just disable syntax highlighting in python-mode for the specific keyword, it should be fine? Is that possible to do in elisp?

  • sping@lemmy.sdf.orgEnglish
    2·
    5 months ago

    It does seem like a bug, but also exactly the sort of thing that tree sitter solves. I bet this doesn’t happen in python-ts-mode.

    • rglullisOPMAEnglish
      1·
      5 months ago

      Is it easy to integrate with elpy?

      • sping@lemmy.sdf.orgEnglish
        2·
        5 months ago

        Pretty much unrelated AFAIK. At least in the setup I have it does mean that various hooks you may have set up may have to be tweaked. e.g. I had things on python-mode-hook but now I have to use python-ts-mode-hook.

        For me it was

        • install tree-sitter (sudo apt install lib-tree-sitter-dev)
        • build Emacs with tree-sitter
        • configure tree-sitter with the snippet below
        • mess with some config/hooks because my prog modes are now different

        Some setups seem to make <lang>-ts-mode somehow aliased to <lang>-mode, and I don’t know if that makes the hook issue automatically resolved (?). Apart from that, treesit-auto seemed to be a low-friction way to get a setup:

        My config:

        (use-package treesit-auto
  :custom
  (treesit-auto-install 'prompt)
  (treesit-font-lock-level 4)
  :config
  (treesit-auto-add-to-auto-mode-alist 'all)
  (global-treesit-auto-mode))

        Edit: and I can confirm that treesitter does fix your specific problem, unsurprisingly.