-
Notifications
You must be signed in to change notification settings - Fork 119
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
Support <template> tags for Glimmer #208
Conversation
I could use some help, if ya'll'd be so kind <3
|
@NullVoxPopuli we should create a See issue #213 |
@NullVoxPopuli you need the
With the above, the The more direct install, which I prefer, consists in installing
For parsing just a file, use this:
For parsing a snippet when using bash, I recommend using process substitution so you don't have to create a file:
FWIW, this is the script we use to install the |
how do you edit the js parser? it's 74k lines and is too much for my editor 😅 🤔 I'm wanting to "change languages" when I encounter a |
ok, I'm back at this -- I've pushed up some tests for kind of what I'm expecting to happen. Is there a way to setup tree-sitter for testing that injections are working appropriately? I noticed that for JSDoc, the whole thing is just "comment". in the TS Playground, I can toggle injections and then I see
for /*
* @return {void}
*/
function foo() {} My hope is that I can at least test that the injection is supposed to happen (and then do the same for the glimmer injections) -- (I understand that if we were to test full AST of all injections, we'd have circular dependencies, and that'd get wonky) |
I'm starting to think this isn't possible without changing parser settings? The main thing I'm running into as that entire Unrelated, or maybe it is related -- but could have JSX been a separate parser / syntax with injections into javascript? if that's theoretically possible, than so should this Glimmer stuff 🤔 |
I think the problem, If I'm understanding correctly, is that injections only control highlighting.. they can't stop parsing from the host language -- which is what I think I need to have happen. |
ef8d87b
to
2efc7dc
Compare
@maxbrunsfeld, @mjambon ready for review |
|
||
; Ember Unified <template> syntax | ||
; e.g.: <template><SomeComponent @arg={{double @value}} /></template> | ||
((glimmer_template) @glimmer) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
bump <3 |
@maxbrunsfeld, may I request a review? |
Bump @mjambon ? <3 |
</template>; | ||
|
||
<template> | ||
<WithSemi /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So whatever is inside the is not really parsed/recognized?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Correct, that's handled by tree-sitter-glimmer via injections
I'd rather see this outside base-javascript, but jsx is already in, so why not glimmer. |
I'd love to see a movement more where jsx (and other flavors) are additions, rather than builtin -- makes more sense architecturally, I agree <3 |
Awesome @NullVoxPopuli 🎉 |
aaand typescript update: tree-sitter/tree-sitter-typescript#218 |
Supports
<template>
tags for GlimmerChecklist:
Images of what this enables (+the injected grammar (glimmer))
Originally, I thought I could "just use injections" to hijack JSX parsing to give the
<template>
tags different highlighting -- this doesn't work tho because tree-sitter-javascript is still going to parse everything as JSX (even if there is an additional highlighting injection which parses as glimmer (via tree-sitter-glimmer). This created TOOOOONS of ERROR nodes, and weird partially recovered nodes in the tree.The easiest path forward here was to add
<template>
parsing and allowtree-sitter-glimmer
to take over from there.One thought I had, which I feel like keeps coming up throughout all of JS is that it seems integration JSX directly into JS parsers leads to soft-blocking other tools that want to use similar syntax -- a design we may want to consider in the future is removing JSX from base-javascript parsing (but providing tools to match on
<...>
and</...>
(and<>
/</>
), so that separate parsers can then highlight the contents. This would make things a bit more modular, and would support JSX, TSX, Glimmer, Svelte, etc all as separate packages that can use injections for the content within the<...>
nodes. Though, even though the modularity of this idea is a bit exciting to me, the amount of effort to migrate things that way feels enormous (esp dealing with the social / semver contracts, etc)