search

gleam-lang / tree-sitter-gleam

🌳 A tree-sitter grammar for the Gleam programming language
Apache License 2.0
71 stars 13 forks source link

refactor named nodes within bit-string options? #19

Closed the-mikedavis closed 2 years ago

the-mikedavis commented 2 years ago

With some code like so

<<code:int-size(8)-unit(2), reason:utf8>>

which gives

(bit_string
  (bit_string_segment
    value: (identifier
    options: (bit_string_segment_options
      (bit_string_segment_option_int)
      (bit_string_segment_option_size
        (integer))
      (bit_string_segment_option_unit)))
  (bit_string_segment
    value: (identifier)
    options: (bit_string_segment_options
      (bit_string_segment_option_utf8)))))))

I'd like the named nodes within the options field of bit_string_segment to be a little more generic so I can capture them in a highlight query and give them a special highlight. Something like

; captures unit, "size", "utf8", "int", etc.
(bit_string_segment_option) @function.builtin

so it might be parsed like so instead:

(bit_string
  (bit_string_segment
    value: (identifier
    options: (bit_string_segment_options
      (bit_string_segment_option)
      (bit_string_segment_option
        (integer))
      (bit_string_segment_option)))
  (bit_string_segment
    value: (identifier)
    options: (bit_string_segment_options
      (bit_string_segment_option)))))))

The nodes come out to be less specific than they are currently, but I think that's ok because you could do something like:

((bit_string_segment_option) @utf8
 (#eq? @utf8 "utf8"))

What do you think, would you be open to a PR that makes a refactor like this?

J3RN commented 2 years ago

I waffled on this for a bit, but I think this change is fine. As you mentioned, since the queries capture the text of the node I don't think we're actually losing information here, just storing it differently. So long as the options can be determined one way or another, it's fine :+1: Besides, the new AST looks much cleaner :sweat_smile: