Closed rolandwalker closed 2 years ago
This may not be the best implementation. Is this really the easiest way to access the list of named node types?
There isn't a function that list a language's node types. I think such a function would be useful. In this case though, we can check whether a node type is valid using tsc-node-type-id
.
Also, per your comment, you haven't decided whether
STRICT
should be optional.In my own contributions to pygn-mode, I am leaning on the non-strict expectation for forward compatibility with node-types which are not yet released in tree-sitter-langs. But that is just one data point, and not a big deal to change.
I think the default should be strict, with an optional parameter IGNORE-INVALID-TYPE
to turn it off, which can be used by code that wants to be forward-compatible. (I can't think of anything more concise.)
tsc-lang-node-type-id
Ah, that's much better.
We should define a new error symbol
Done: tree-sitter-invalid-node-type
.
Anonymous node types should also be checked
Done.
I think the default should be strict, with an optional parameter
IGNORE-INVALID-TYPE
Done. ACCEPT-INVALID-TYPE
might also make sense.
There isn't a function that list a language's node types. I think such a function would be useful.
FTR my first attempt at that in Lisp (overwritten by force-push) was:
(defun tree-sitter--list-named-node-types ()
"List all named node types for the current tree-sitter language."
(mapcar
'(lambda (id) (tsc-lang-node-type tree-sitter-language id))
(delq nil
(mapcar
'(lambda (id) (when (tsc-lang-node-type-named-p tree-sitter-language id) id))
(number-sequence 0 (1- (tsc-lang-count-types tree-sitter-language)))))))
https://github.com/emacs-tree-sitter/elisp-tree-sitter/pull/171#issuecomment-912477047
This may not be the best implementation. Is this really the easiest way to access the list of named node types?
Also, per your comment, you haven't decided whether
STRICT
should be optional.In my own contributions to pygn-mode, I am leaning on the non-strict expectation for forward compatibility with node-types which are not yet released in tree-sitter-langs. But that is just one data point, and not a big deal to change.