Suggestion to introduce var_spec_list for improved consistency

[anthony-S93]

Code sample:

package main

import (
    "fmt"
    "flag"
)

var (
    x int = 99
    y int = 100
)

func main() {
    fmt.Println(x)
    fmt.Println(y)
}

Parser output:

(package_clause) ; [1:1 - 12]
 (package_identifier) ; [1:9 - 12]
(import_declaration) ; [3:1 - 6:1]
 (import_spec_list) ; [3:8 - 6:1]       <<< Introduce an equivalent node (var_spec_list) for var_declaration?
  (import_spec) ; [4:5 - 9]
   path: (interpreted_string_literal) ; [4:5 - 9]
  (import_spec) ; [5:5 - 10]
   path: (interpreted_string_literal) ; [5:5 - 10]
(var_declaration) ; [8:1 - 11:1]
 (var_spec) ; [9:5 - 14]
  name: (identifier) ; [9:5 - 5]
  type: (type_identifier) ; [9:7 - 9]
  value: (expression_list) ; [9:13 - 14]
   (int_literal) ; [9:13 - 14]
 (var_spec) ; [10:5 - 15]
  name: (identifier) ; [10:5 - 5]
  type: (type_identifier) ; [10:7 - 9]
  value: (expression_list) ; [10:13 - 15]
   (int_literal) ; [10:13 - 15]

[amaanq]

Hm, taking a look at that and the go grammar - I would say the opposite, that import_spec_list shouldn't exist just like with var_spec, would that consistency be good for your use case?

[anthony-S93]

Hm, taking a look at that and the go grammar - I would say the opposite, that import_spec_list shouldn't exist just like with var_spec, would that consistency be good for your use case?

My use case is trivial, to be honest. I was simply looking for a way to apply consistent highlighting rules for indent lines. I'm currently using a plugin called indent-blankline. The plugin itself allows us to highlight the indent line associated with the scope that the cursor is in:

https://github.com/tree-sitter/tree-sitter-go/assets/69449791/fea35c0d-3e94-49f3-920e-184a441dde21

Notice how the indent line for the var_declaration block is immediately highlighted when the cursor reaches the declaration's header? For the import_declaration block, the indent line is only highlighted when the cursor moved past the header line. The latter behavior seems more intuitive to me, but there's no way to implement it without var_spec_list, which defines the scope for the highlighting to apply.

[amaanq]

Hm, maybe the plugin should account for nodes with repetitions in them - though I can imagine that's much more complicated than adding a rule here. Though I'll be honest, I'm not a fan of the *_spec_list rules since it's not listed in the go spec and isn't really needed for this grammar

[anthony-S93]

Though I'll be honest, I'm not a fan of the *_spec_list rules since it's not listed in the go spec and isn't really needed for this grammar

I understand. The parser also implements parameter_list and argument_list rules, but those are actual lists (they are essentially tuples with comma-separated tokens). In contrast, import_spec_list technically isn't a list in the strictest sense (the tokens it contain are not separated by commas), at least not in the same sense that applies to parameter_list and argument_list.

Either way, I'll leave this issue open just in case someone else has other suggestions.