The function f given as argument to update isn't highlighted as a function

[oryband]

See example:

[oryband]

Might be worth checking this in sibling functions such as update-in etc. as well.

[sogaiu]

I'll try to explain a bit of why this type of thing may not be practical (with the current capabilities of tree-sitter). If I mention things you know already, please feel free to skip those parts. It's a bit long but I hope it can clarify things.

The reason update, assoc, etc. are highlighted specially is because one of the patterns in the highlighting query (note: not a part tree-sitter-clojure's grammar, but a part of nvim-treesitter) makes a kind of a guess: https://github.com/nvim-treesitter/nvim-treesitter/blob/d779ee79f0426711f84b770bf6ff4afda4f41c1e/queries/clojure/highlights.scm#L53-L58

That pattern recognizes lists that look a certain way -- so it's a guess that it's a function invocation. It won't be correct in every case but it's a "better than nothing" effort.

The tree-sitter-based highlighting capabilities of neovim are constrained by what one can do via tree-sitter's queries.

Also, tree-sitter queries operate based on what a grammar recognizes, but the tree-sitter-clojure grammar doesn't recognize things like functions, but rather lower level constructs like lists, sets, numbers, etc.

To give some background on why this is, FWIW, there were two earlier attempts by oakmac and Tavistock at tree-sitter-clojure which tried to do this but were not very accurate IMO. When I tried them against large samples of human-created Clojure source, I found the grammars produced a lot of errors. I tried to build and improve on them for some time but ultimately concluded that it wasn't practical. The current approach to only recognize lower level constructs was only chosen after those earlier experiences. I made a decision to favor more correct operation at the expense of not recognizing various higher level constructs. IMO, part of the difficulty is the lack of an official spec for Clojure, but another part of it is a mismatch between tree-sitter and typical lisps.

As a side note, tree-sitter stuff is not just about highlighting -- with a decent grammar, I think things like structural navigation and editing implementations might be aided. (I've done some related implementation work for this for emacs-tree-sitter-based things so I know it is doable.) I actually have more hopes for the non-highlighting possibilities and the choices I made for this grammar reflects that.

So to address the issue description, it's not clear to me how one would do what you are suggesting in a practical manner that won't turn into many special cases (and even then getting the perfomance to be decent might be tricky) -- at least if we are thinking to apply tree-sitter. You are welcome to try of course -- IIUC, nvim-treesitter provides a mechanism for user-customizable queries: https://github.com/nvim-treesitter/nvim-treesitter#adding-queries

There might be another approach to achieve the sort of thing you described -- via clojure-lsp. I'm not sure what it can do currently, but since it now leverages clj-kondo (which does static analysis), I think it might be in a much better position to do significantly more sophisticated highlighting.

[sogaiu]

I'm going to close this as I think the issue lies elsewhere, but if it turns out otherwise, it can be reopened.