search

SublimeText / PackageDev

Tools to ease the creation of snippets, syntax definitions, etc. for Sublime Text.
MIT License
436 stars 83 forks source link

Highlight YAML tags in .sublime-syntax #93

Closed FichteFoll closed 7 years ago

FichteFoll commented 7 years ago

See https://forum.sublimetext.com/t/looking-for-packagedev-alpha-testers-sublime-syntax-highlighting/24270/33?u=fichtefoll for an actual use case (tl;dr pre-processing).

Thom1729 commented 7 years ago

I was going to just add this to the prototype, but I noticed that the syntax doesn't use one. Is this simply because it is descended from a tmLanguage, or is there a reason to avoid using a prototype (along with the occasional meta_include_prototype: false)?

FichteFoll commented 7 years ago

https://github.com/SublimeTextIssues/Core/issues/1062 left a bad taste in my mouth, which is why I sheered away from using prototype in most situations as I was expecting more issues to arise. I've since used explicit includes for most syntaxes, which is more flexible.

I'd need to invesitage whether adding a prototype with comments and tags (similar to what I did in the YAML syntax) will be worth it in this case and in the long run. For now, I'd probably only add an include to the various expect_* contexts.

Thom1729 commented 7 years ago

That is a strange and fascinating bug.

In my personal experience, I've found prototypes to decrease bugs, because then I have a single inclusion to test. If I include comments in a hundred scopes, then I have to write hundreds of tests, and it's a lot of clutter and a lot of room for bugs. (It also combines very poorly with the heavily stack-based architecture I prefer, although macros can somewhat alleviate this.)

Your mileage may vary. In the meantime, I'll write up a PR for this issue using the existing style.

Is it worth creating a separate issue to explore the prototype question? I wouldn't mind doing the conversion work just so we can see it.

FichteFoll commented 7 years ago

Yes, feel free to explore using prototypes in a separate branch, preferrably based on the PR for the existing style which makes merging easier.

Make sure to properly identify the scopes where it needs to be excluded and take a look at the syntax test file to spot any lines that aren't properly scoped as comments (since that file has a lot of them due to it being the test line marker). Also add a prototype include to the main scope because of the referenced bug.

The one thing I'm still curious about prototypes is whether they get carried over to included syntaxes or whether they are only added to contexts within that same file. I hope it's the latter, which would make the most sense, but I never bothered actually investigating.