Scope names aren't at all the recommended ones.

[willstott101]

Currently in large projects Sublime can get rather slow when using these syntax definitions, probably partly due to the complexity of the syntax, but also there seem to be far too many symbols being added to the index so hovering over something to see definitions, can end up with a lot of results.

I believe part of the problem is that the scopes used for the tmLanguage definitions for TypeScript hardly match the recommended ones at all: https://www.sublimetext.com/docs/3/scope_naming.html

As far as I can tell, sublime's decision on whether something is a definition or a reference is non-configurable and is hidden in Sublime somewhere. So we'd need to actually edit the scope names in the tmLanguage to fix this.

Would you be interested in a python script we can run on the tmLanguage file to fix their sublime-unfriendly scopes? I could have a go if it's something you'd be interested in.

Although I understand this is just a re-publish I actually think it's most relevant here... because properly supporting the built-in sublime tools is probably something the beefy Typescript package doesn't care about. As of yet IDK just how much the syntax definitions would have to change - and if it would become incompatible with VSCode. So I'd rather get it working here first, all be it, as a simple find-replace script.

[braver]

If we want to do this right, we abandon compatibility with the upstram package from MS. It is also used in the TypeScript package for Sublime, but it's not their main focus of course. And it's a terrible package anyway.

So, upgrading to sublime-syntax format and then fixing the scopes would be nice, but not something I want to maintain.

That said, it should be possible to tweak the symbol indexes etc. by pointing Sublime to different scopes (ie. what you're attempting in #4).

So if you can get that PR to work, that would be nice. I don't mind the idea of someone doing a proper ST3-focussed syntax, but I can't put more time into it than I do right now (which is around 10 minutes per year).

[willstott101]

Yeah reasonable, I'll try and take another look into how the indexes choose if something is a reference or definition, someone somewhere ought to know if it's possible to configure.

Outside of that, a sublime-syntax definition may be better long-term, but as you say, it's a butt load of work - especially for a language as complex as typescript.

I'll probably keep pursuing this - at least for a while, and I'll keep you updated, but try and stay independent so you don't have to think about it ;)

[braver]

ST has a utility to convert to a sublime-syntax file, and they’re easy enough to work with. So the initial syntax set up and tweaking the scopes should be easy enough. The question is mostly how fast the TS syntax is moving (it’s actually pretty stable probably). So it’s nothing to be scared of. I’m just not using it myself these days, and I’ve got a bunch of other packages that are taking my time. But if you’re up for it I can help out here and there.

[braver]

Actually, I was thinking that maybe a better approach would be to start with the default JS syntax and then graft the specific TS stuff onto it. Just a thought.

[willstott101]

I'm going to close this as #4 worked, and it shows that using recommended scope names is useful but not really much of an issue.

[michaelblyons]

Actually, I was thinking that maybe a better approach would be to start with the default JS syntax and then graft the specific TS stuff onto it. Just a thought.

Looks like someone is doing so. Thom1729/Sublime-JS-Custom#51

[braver]

Yes, and not just anybody either. I’ve good hopes for that project

[michaelblyons]

And now it's getting added to ST4 built-in syntaxes. 😳

[braver]

I know! 🍾