looks good to me overall. just would like to double check if we really need to instantiate the tree sitter parser with every request 😢. can't we just mutate the tree?

I think I would shy away from that – we would mutate the tree that is also used for other features… seems like a source of very annoying bugs :/

Also, keep in mind that:

1. the statement is likely pretty small and the parsing should happen quickly and
2. that we don't need to create a tree and will reuse the existing one if the user has already written a letter.

I added some benchmarks – on my machine, reusing the old treesitter takes about 500 nanoseconds, and creating a new one about 5-150 microseconds depending on the size of the sql.

I mean, I can play a Counterspell when I see a hakbal in about that time, but I wouldn't mind waiting that long for completions

@psteinroe Curious about your opinion: I tried moving theGetCompletionsMapper into the completions crate, but then I couldn't access theparser.cst_db because that's private. But it's weird to write feature-functions and comments into the parsed_document I think :/

We could make theparser.cst_db public, or provide aparser.get_tree() method, or leave the mappers in the crate… what do you think?

ah sorry, i didn't mean to move the mapper there. I was thinking to clone or copy the tree sitter parser to skip the initialisation costs.

Will look at the pr later, thanks for trying! 🙏🏼