Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expose template string chars as nodes? #275

Closed
helixbass opened this issue Nov 14, 2023 · 1 comment · Fixed by #288
Closed

Expose template string chars as nodes? #275

helixbass opened this issue Nov 14, 2023 · 1 comment · Fixed by #288

Comments

@helixbass
Copy link
Contributor

It seems unexpected that if you traverse the "leaf" nodes of an AST with a template literal (that has some text content) there are no leaf nodes that contain that text content

For example for the source code `abc` the template_string node has child nodes for `/` but not abc

This appears to be asymmetrical wrt "regular" strings, which surface their contents as string_fragment's

(and more generally I guess it violates some vague "invariant"/expectation I have that a node should either be a "leaf" node (ie have no child nodes) or else all of its non-whitespace characters should be encapsulated by some child node, no idea whether this is actually "a thing" or not)

My use case is that I basically want to compare whether two template strings are "identical" (as far as content/AST structure, so eg `abc${d}efg` and `abc${ d }efg` should be considered "identical" even though they're not source-text identical) and this would presumably be way easier if the text content (here, abc/efg) were exposed as nodes (then I could just do leaf-node-by-leaf-node comparison)

I will open a PR that basically attempts to fix this by changing _template_chars -> template_chars, but I think I ran into something with highlighting/injection that makes it impossible to maintain existing behavior while adding this change

@helixbass
Copy link
Contributor Author

Actually I think the highlighting/injection issue is possibly resolved "enough", so #276 should be reviewable/potentially mergeable

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant