The core JavaScript syntax uses the top-level scope source.js, and various features (such as the toggle_comment command) rely on that. JS Custom syntaxes default to more detailed top-level scopes like source.js.myconfiguration, which should work just as well. However, if you use the scope option to specify a custom scope like source.ts (e.g. for compatibility with other tools), then toggle_comment won't work (see #98).
This PR patches this problem for the common case by:
Explicitly defining JS-style comments for the source.js, source.ts, and source.tsx scopes.
Explicitly defining JSX comments for the source.js, source.ts, and source.tsx scopes.
Modifying the automatic jsx_close_tag functionality to match the selector source.js, source.ts, source.tsx.
This should work well for most people in most cases. However, it's not a perfect solution:
Hardcoded scopes won't work for other custom scopes. (I can't think of a reason to specify a custom scope not on the list, but I'm sure there's a reason out there.)
These hardcoded values could theoretically conflict with another package; for instance, if someone is using JS Custom alongside a dedicated TypeScript package. I think this probably shouldn't cause problems, but I can't rule it out.
I'll probably merge this for now, but in the long run I'll be looking at alternatives. One option is dynamically generating tmPreferences files alongside the compiled syntaxes. If I go that route, it probably won't be before v3.0.
The core JavaScript syntax uses the top-level scope
source.js
, and various features (such as thetoggle_comment
command) rely on that. JS Custom syntaxes default to more detailed top-level scopes likesource.js.myconfiguration
, which should work just as well. However, if you use thescope
option to specify a custom scope likesource.ts
(e.g. for compatibility with other tools), thentoggle_comment
won't work (see #98).This PR patches this problem for the common case by:
source.js
,source.ts
, andsource.tsx
scopes.source.js
,source.ts
, andsource.tsx
scopes.jsx_close_tag
functionality to match the selectorsource.js, source.ts, source.tsx
.This should work well for most people in most cases. However, it's not a perfect solution:
I'll probably merge this for now, but in the long run I'll be looking at alternatives. One option is dynamically generating
tmPreferences
files alongside the compiled syntaxes. If I go that route, it probably won't be before v3.0.