Differentiate line and block comments

[Aerijo]

Requirements

• Filling out the template is required. Any pull request that does not include enough information to be reviewed in a timely manner may be closed at the maintainers' discretion.
• All new code requires tests to ensure against regressions

Description of the Change

Tree-sitter currently treats all comments as comment.block. However, the distinction between block and line can be useful

For example, I'm trying to write a script that auto-comments newlines when created inside a line comment. I don't want it to do this inside a block comment, but it's difficult to tell which it is using the provided scopes. E.g., the desired behaviour is

// some |text

// some
// |text

but in an actual block comment, we would get

/*
some |text
*/

/*
some
// |text
*/

Alternate Designs

The Tree-sitter grammar could differentiate comments.

Benefits

More precise scoping

Possible Drawbacks

Regular expressions can hurt performance. Hopefully, it can optimise this one, as it's only a constant two character check each time. It'd still feel better if there was a rule to match an exact start string (so just //).

Applicable Issues

NA

[thomasjo]

Line comments can appear anywhere on a line; this only handles cases where it's at the beginning of a line.
We need tests that explicitly handles various line comment scenarios.

[Aerijo]

@thomasjo The regex here refers to the start of the comment node, which should always be // if it's a simple line comment. It will catch comments at the end of a line

I'll add more tests though

[thomasjo]

Aaaha, thanks for clarifying that

[Aerijo]

Actually, I didn't add tests the first time because none exist yet. I guess I'll (try and) make a new set for Tree-sitter.

[Aerijo]

Emphasis on try. There's no point in testing the tree; that's done by the parser's package. And I'm having trouble getting the scopes.

[maxbrunsfeld]

I'm ok with not having tests on these scope mappings. The actual parsing is tested very exhaustively, but testing these kinda feels like testing CSS, or testing a config file.

If you have a strong desire to add tests, I'm ok with it, but I'm also cool merging this as-is.

[Aerijo]

• I think tests are a good idea for the Atom specific behaviour, but was unable to get it working
• This issue can be raised on almost all the repos though, as they all treat comments as blocks

[Aerijo]

OK, I've given up on tests. I still think they're a good idea in the long run, but this change is pretty benign.

@maxbrunsfeld I plan to raise this on all the repos using TS, as there is nothing particularly special about JavaScript.

[daviwil]

Looks good to me, thanks @Aerijo!

Clarification in the comments