MegaIng

This is a bug in the way lark combines terminals, #1415 fixes it.

`choices()` returns the terminals that have a transition in the state machine from the current state. But following that transition might lead to errors further down the line, see #646...

I don't think there is a fundamentally different approach that avoids copying the parser state. But it might be possible to avoid deep-copying the `value_stack`, which I suspect is the...

There is now another repo https://github.com/lark-parser/vim-lark-syntax, by @omega16. If you two have any suggestion, you can help improve that repo.

See https://github.com/lark-parser/lark/issues/1371 It's not exactly easy and especially for C-like syntax that is already tricky to parse with lark it might be quite annoying.

As it says in the error message, the terminal can't be zero width. Use `/.+/?` instead.

Use `ambiguity='explicit'` and manually select the correct parse, see https://github.com/lark-parser/lark/blob/master/examples/advanced/dynamic_complete.py Or choose the easier and quicker root and use the `scan` function I coded up in the other issue.

Yeah, that does indeed look like a bug, maybe @erezsh has an idea what is going on. With regard to `scan`: You have to do a bit of extra work...

This function should do what you want using the scan method: ```py def scan_and_replace(parser: lark.Lark, text: str, replacement: Callable[[lark.ParseTree], str], start: str = None) -> str: """ Scans the `text`...

@erezsh No, what actually fixed it is moving `/.+/?` into a separate rule. These two grammars should have the same behavior, but don't: ``` grammar = f""" start: any? expr+...