My typical rule of thumb is that if both branches of a pattern-match are being modified through some methods, it's clearer to replace that with an explicit pattern match. So something like:

let parser = match parser.entry(parser_id) {
    Occupied(p) => p.reset(); ...
    Vacant(v) => v.insert(parser_id.get_parser())
}

Otherwise, a method name like and_modify doesn't make it super clear what is happening, and a comment shouldn't be necessary for what is otherwise boring code.

Happy to make the change, though the comment wasn't really about and_modify and more about the tree-sitter API requiring the use of .reset() when parsing a new document.

In that case, a clearer comment would be something like Tree-sitter parsing is stateful, so reset the parser state explicitly.

Actually I take that back. This is one of the cases where the entry API seems to be the easiest way to make the lifetimes work out. (I can't get a mutable reference from Occupied which I need to call .reset() on it)

I've removed the comment

This doesn't work? https://doc.rust-lang.org/std/collections/hash_map/struct.OccupiedEntry.html#method.get_mut

Damnit, the UI didn't reload so I missed your comment.

This doesn't work? https://doc.rust-lang.org/std/collections/hash_map/struct.OccupiedEntry.html#method.get_mut

It does give you a mutable reference, but you can't return it from the match after resetting, as it's bound to the lifetime of the pattern matched entry value.

This one then? https://doc.rust-lang.org/std/collections/hash_map/struct.OccupiedEntry.html#method.into_mut

Neat, that one worked.