feat(angular): add angular syntax highlighting #4
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
atscott
reviewed
Nov 3, 2023
|
Tested with the Angular control flow syntax and other Angular template syntax highlighting in a random HTML file (not an Angular project). It's not ideal but it's not awful either. I can live with it.
|
atscott
added a commit
to atscott/vscode-ng-language-service
that referenced
this pull request
Nov 6, 2023
Template scopes do not need to be injected directly to source.ts. Instead, template scopes apply when inline templates have been matched in TS files and are included as patterns under that match. The Angular template syntaxes _could_ be directly injected into TS like they are now. This would apply them to any embedded `text.html` in a TS file. This change applies Angular template grammars only to embedded HTML matched by the inline template grammar (strings under `template:` of a decorator). `injectTo` applies only to the top-level file language and not embedded labguages. So our `injectTo` `text.html` will not automatically apply to inline templates simply by setting the `contentName` and language. It would also be nice to further limit our grammars to apply only to files that we know are Angular templates rather than injecting to every to-level `.html` file. In the future we might want to explore _not_ injecting into all top-level `html` and then using `injectionSelector` to control from there. This approach makes it difficult for environments that support many frameworks/languages (stackblitz/textmate#4). We might be able to create an "angular" language for `.component.html` and `.ng.html` files and use our grammars only for those extensions rather than injecting them into any and all `html`.
atscott
added a commit
to atscott/vscode-ng-language-service
that referenced
this pull request
Jul 1, 2024
Template scopes do not need to be injected directly to source.ts. Instead, template scopes apply when inline templates have been matched in TS files and are included as patterns under that match. The Angular template syntaxes _could_ be directly injected into TS like they are now. This would apply them to any embedded `text.html` in a TS file. This change applies Angular template grammars only to embedded HTML matched by the inline template grammar (strings under `template:` of a decorator). `injectTo` applies only to the top-level file language and not embedded labguages. So our `injectTo` `text.html` will not automatically apply to inline templates simply by setting the `contentName` and language. It would also be nice to further limit our grammars to apply only to files that we know are Angular templates rather than injecting to every to-level `.html` file. In the future we might want to explore _not_ injecting into all top-level `html` and then using `injectionSelector` to control from there. This approach makes it difficult for environments that support many frameworks/languages (stackblitz/textmate#4). We might be able to create an "angular" language for `.component.html` and `.ng.html` files and use our grammars only for those extensions rather than injecting them into any and all `html`.
atscott
added a commit
to atscott/vscode-ng-language-service
that referenced
this pull request
Jul 1, 2024
Template scopes do not need to be injected directly to source.ts. Instead, template scopes apply when inline templates have been matched in TS files and are included as patterns under that match. The Angular template syntaxes _could_ be directly injected into TS like they are now. This would apply them to any embedded `text.html` in a TS file. This change applies Angular template grammars only to embedded HTML matched by the inline template grammar (strings under `template:` of a decorator). `injectTo` applies only to the top-level file language and not embedded labguages. So our `injectTo` `text.html` will not automatically apply to inline templates simply by setting the `contentName` and language. It would also be nice to further limit our grammars to apply only to files that we know are Angular templates rather than injecting to every to-level `.html` file. In the future we might want to explore _not_ injecting into all top-level `html` and then using `injectionSelector` to control from there. This approach makes it difficult for environments that support many frameworks/languages (stackblitz/textmate#4). We might be able to create an "angular" language for `.component.html` and `.ng.html` files and use our grammars only for those extensions rather than injecting them into any and all `html`.
atscott
added a commit
to angular/vscode-ng-language-service
that referenced
this pull request
Jul 2, 2024
* refactor(extension): clean up embedded language configuration The embeddedLanguages configuration of a grammer is meant to map scope name to the name of the language for that scope. * refactor(syntaxes): Only inject template scopes to html Template scopes do not need to be injected directly to source.ts. Instead, template scopes apply when inline templates have been matched in TS files and are included as patterns under that match. The Angular template syntaxes _could_ be directly injected into TS like they are now. This would apply them to any embedded `text.html` in a TS file. This change applies Angular template grammars only to embedded HTML matched by the inline template grammar (strings under `template:` of a decorator). `injectTo` applies only to the top-level file language and not embedded labguages. So our `injectTo` `text.html` will not automatically apply to inline templates simply by setting the `contentName` and language. It would also be nice to further limit our grammars to apply only to files that we know are Angular templates rather than injecting to every to-level `.html` file. In the future we might want to explore _not_ injecting into all top-level `html` and then using `injectionSelector` to control from there. This approach makes it difficult for environments that support many frameworks/languages (stackblitz/textmate#4). We might be able to create an "angular" language for `.component.html` and `.ng.html` files and use our grammars only for those extensions rather than injecting them into any and all `html`.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds TextMate grammars for syntaxes used by Angular, based on the latest syntaxes from https://github.com/angular/vscode-ng-language-service, including the Angular 17 control flow syntax.
Apparently there is no Angular templating language, only Angular-specific grammars for syntaxes embedded in other languages, especially in TypeScript (provides highlighting for template strings in TypeScript files) and in HTML. This PR adds 5 JSON grammars.
In my tests, when plugged into the StackBlitz classic editor, this leads to most projects (including non-Angular projects) fetching those 5 JSON grammars, as long as the project has a TypeScript or HTML file.
I’m a bit wary of those extra requests for all projects, but maybe that's an issue that we want to address separately.