New queries for `java` and `lua`

[kawre]

The new lua query might need to be tested because the field node is quite broad in range

So when the key isn't surrounded by brackets it might match other brackets inside field. But by the picture i sent it seems like this case is already handled or maybe i don't quite understand how the queries work

[Danielkonge]

I don't see how the new Lua query would be problematic, since we probably want to highlight [ and ] in other cases too, where it might be parsed as field? (If you have seen other cases, where we get a field?)

In your example [] is inside a string and thus not parsed as part of field, so it won't be highlighted, and I can't think of any examples where you can have [ and ] around the value? Also, even if you can, presumably we would want to highlight that too?

[kawre]

It's just a small thing I noticed that could cause some unexpected behaviors, but by what you're saying, those queries match only the characters that belong to the parent but are not a part of any other children, so by that logic, it should indeed work fine.

I just though that queries search for matches in the entire text of the parent, rather than its stray characters. But like I said, I'm not an expert in treesitter queries, so better to mention these things than not.

[Danielkonge]

It's just a small thing I noticed that could cause some unexpected behaviors, but by what you're saying, those queries match only the characters that belong to the parent but are not a part of any other children, so by that logic, it should indeed work fine.

Yes, that is correct. Your query won't match any [, ] inside name: ... or value: ... in the given example.

I just though that queries search for matches in the entire text of the parent, rather than its stray characters. But like I said, I'm not an expert in treesitter queries, so better to mention these things than not.

I also only started learning about treesitter a few months ago, and it does take a bit of getting used to, but after working with it a bit, it is luckily not too complicated. :)

The queries are pretty literal (if that makes sense?), in that they only match the exact pattern you write. So they don't match inside any of their children.

[HiPhish]

Merged, thank you.

I just though that queries search for matches in the entire text of the parent, rather than its stray characters. But like I said, I'm not an expert in treesitter queries, so better to mention these things than not.

Correct, literal strings match anonymous nodes exactly. If you want to match a part of a node or a text pattern you have to use predicates (:h treesitter-predicates). I think this only works with named nodes though, not anonymous nodes.