AST breaks with ( in declaration section

[aMOPel]

let 
  a: int = 

let_section [93, 0] - [94, 10]
  "let" [93, 0] - [93, 3]
  variable_declaration [94, 2] - [94, 8]
    symbol_declaration_list [94, 2] - [94, 3]
      symbol_declaration [94, 2] - [94, 3]
        name: identifier [94, 2] - [94, 3]
    type: ":" [94, 3] - [94, 4]
    type: type_expression [94, 5] - [94, 8]
      identifier [94, 5] - [94, 8]
  ERROR [94, 9] - [94, 10]
    "=" [94, 9] - [94, 10]

when typing ( it breaks the (let_section)

let 
  a: int = (

"let" [93, 0] - [93, 3]
symbol_declaration_list [94, 2] - [94, 3]
  symbol_declaration [94, 2] - [94, 3]
    name: identifier [94, 2] - [94, 3]
":" [94, 3] - [94, 4]
type_expression [94, 5] - [94, 8]
  identifier [94, 5] - [94, 8]
"=" [94, 9] - [94, 10]
"(" [94, 11] - [94, 12]

[alaviss]

I have a fix for this by restructuring how statements might end, but the parser size grew over 100MiB, which is over GitHub's limit.

I think we will have to consider working with downstream users about downloading parser via GitHub Releases or similar mechanism. It is clear that parsing Nim correctly requires a very big parser.

[aMOPel]

That would mean rolling out your own download/build tool and not using the service of nvim-treesitter.

Plus, moving our queries out of nvim-treesitter would greatly reduce discoverability.

You could make it part of your nim.nvim plugin I guess. Still wouldn't be where I would expect to find the treesitter parser/queries.

[aMOPel]

Is it not possible to add LFS to the repo and still have everything work as before? Dunno much about LFS.

[alaviss]

Given that tree-sitter 1.0 have "not shipping parser.c within repo" as a goal, I think sooner or later all downstreams will have to move.

I'd prefer to have nvim-treesitter carry the parser still, so going that path does require their cooperation.

Git LFS still requires the user to have Git-LFS installed, and not to mention that there is a GitHub-enforced quota for using them, where usage in fork also counts against the main repo...

I'll still work on optimizing the parser size to avoid needing a custom download pipeline, but this is not easy.