Recognise newer forms of package statement

[leonerd]

perl 5.12 added

package NAME VERSION;

perl 5.14 added

package NAME {BLOCK...}
package NAME VERSION {BLOCK...}

Not being a Node expert I'm not sure whether the incidental changes to some of the other files included here are valid (e.g. package-lock.json). Please let me know what's the correct way to handle these, as I'll have several more additions and edits to hopefully send PRs for.

[leonerd]

Actually thinking about this, upstreams may prefer to receive a block form as a package_block instead of package_statement. E.g. thinking about how neovim would apply folding rules differently in either case. Perhaps that is better?

But then I couldn't think of a good name for it to have. Things like if(COND) { ... } have been called "if_statement" here even though that takes a block as well.

[ganezdragon]

can we retain 0.19.4 ? I'm sure anyways node is going to use the latest of the minor version, since ^ is present. But I'm planning to do a upgradation to version 0.20 later, so can we revert this change alone?

[ganezdragon]

@leonerd , this looks good except for the package.json changes, and the conflicts. We could merge it after this is resolved.

[Leeft]

@ganezdragon I don't know if Paul is still active with this (his fork hasn't seen activity for a while as far as I saw), but if not I could redo these changes on a new PR.

[rabbiveesh]

@Leeft we've moved our efforts over to tree-sitter-perl/tree-sitter-perl, b/c this project's parse output is wildly different than what we want.
I believe that our parser there is more correct in many ways, and you may want to take a look there.

[Leeft]

Weird how I missed that one when searching for packages to use; thank you @rabbiveesh, I'll have a look at that one.

[ganezdragon]

this is closed in #25

[ganezdragon]

@rabbiveesh , could you brief on what you are looking out of this parser? for example , my usecase is, I'm looking to use this as a parser for my vscode extension for Perl Language server (IDE support)

[rabbiveesh]

@ganezdragon It's been a long time since I touched your parser, but I recall a lot of choices that you made in the node names + the way it's arranged that made it preferable for me to fork.

IIRC, you have => always parse the left as a hash_key or something. That's just not correct.
You have explicit semicolon nodes, which make your parse output very noisy.

The original reason I started with tree-sitter was because I learned about semgrep, which is a really cool tool built on top of tree-sitter. Although now my main use case is syntax highlighting + folds + other advanced features.

[ganezdragon]

@rabbiveesh , noted. Let me check if I can refactor my code so that it can suit most usecases.

[Leeft]

From my perspective the "noisy" node tree isn't a problem: not having enough structure in the tree is. Some examples:

• A package node should have the file's nodes as its children so what package a node belongs to can be easily located by going up the tree.
• Packing subsequent comment lines into one node is maybe not ideal (a parent "comment block" node that groups individual comment line nodes is great however, giving options). And a Perl comment always starts with # and ends with a newline, doesn't it? Which means subsequent comment lines should be subsequent tree nodes.
• The left hand side of a fat comma => may not always actually be a hash key, but grouping these things into pairs in any case allows a voice coder to change them more easily. Without this grouping that requires additional code to figure out what key belongs to which value.

For voice coding it's important the right elements can be targeted for the scopes of all sizes, and in my case that means matching the scopes that Cursorless can target as well as possible; the node tree needs to be quite verbose for that.