Sublime Forum

How to highlight a nested scope?

#1

Can nested tags be properly highlighted in ST?

I’ve been modifying an existing grammar but am unable to find any way to properly highlight this test case:

{red {green} xxx }

the green tag is embedded inside the red tag. both share the same end character.

red and xxx should both be scoped to “red”.

green should be scoped to “green”.

but the parser doesn’t seem to keep track of nesting, and just sees the first end character as the end. so, red and green both get the red scope, and xxx gets nothing.

for those familiar with ExpressionEngine, the actual test case is:

{exp:channel:entries title="{site_name}" limit="1" {if embed:channel} channel="{embed:channel}" {/if} }

Same problem with this example, which you can paste into a file and set to HTML syntax:

<script> /* </script> */ </script>

0 Likes

#2

(bump)

0 Likes

#3

Having you example here would be pretty nice but maybe I can still help you.

Sublime Text’s language parser supports nesting very well, the only requirement is to use “begin” and “end” matches and than a “patterns” array. If an included pattern’s dimensions go beyond the boundaries of the first valid “end” match it will extend the inner scope to the next “end” match. This is repeated indefinitely.

Example file: github.com/FichteFoll/AAAPackag … tmLanguage

0 Likes

#4

Thanks for the reply.

I have been using the start / end / patterns option in the syntax I’ve been working on. The problems that remain seem largely to have to do with nesting syntaxes within syntaxes, and the real solution to all of this seems to be syntax injection, which would insert EE tag definitions into the existing HTML / PHP definitions… but i havent been able to figure out whether that’s supported in ST. Any idea? Got a working example?

Anyway, my complete code is here:

github.com/fcgrx/ExpressionEngi … t-3-Bundle

Install the package in ST, tehn open the “known_problems.html” file that’s included for a detailed run-down of what doesn’t work… any help would be greatly appreciated!

Thanks again

0 Likes

#5

There is no way to “inject” stuff into other syntax definitons but even though that might be possible with a new plugin which I elaborated in another thread quite a while ago.

The best current way would be to copy the syntax you need, modify it and save it under a different name (while also modifying “name” and “scopeName” values).

Edit: I tried to look at your bundle (and also the known issues) but I was distracted by my AAAPackageDev fork not working correctly with your file so instead I ended up enhancing and fixing that instead.

0 Likes

#6

[quote=“FichteFoll”]There is no way to “inject” stuff into other syntax definitons but even though that might be possible with a new plugin which I elaborated in another thread quite a while ago.

The best current way would be to copy the syntax you need, modify it and save it under a different name (while also modifying “name” and “scopeName” values).

Edit: I tried to look at your bundle (and also the known issues) but I was distracted by my AAAPackageDev fork not working correctly with your file so instead I ended up enhancing and fixing that instead.[/quote]

Thanks for taking a look.

Not sure why you’re putting quotes around “inject” as it’s an established concept in TextMate, which I understand ST’s syntax system is based upon:
blog.macromates.com/2012/injecti … variables/

I considered copying a syntax and modifying it, but that seemed like a hack because any bug fix to the copied syntax would not flow through to my modified version.

Did AAAPackageDev require an enhancement / fix to my package or to AAAPackageDev?

0 Likes

#7

AAAPackageDev required a fix to correctly highlight your syntax definition converted to YAML. (github.com/FichteFoll/AAAPackag … 04fcf3ae1c + a few other enhancements that came to my mind)

But back on the topic – here is a list of what I consider to be useful in the aspect of injecting into syntax definitions:

  • Injecting afterwards: Add a new pattern onto an already highlighted file. This will use a scope name selector and apply the pattern to every Region specified by the scope. Problems: You are limited to the already matched scope and this is not as flexible as actually nested patterns which can extend the matched region if they themselves match beyond it.

  • Injecting before: Injecting a new pattern into an existing syntax file. This would need something to determine its target location such as a scope name which is used in the existing syntax. Then the pattern will either be added at the beginning of the location’s child patterns or at the end (beginning would be required in order to override existing sub-patterns which would interfere with the added pattern). Problem: Only using the target pattern’s scope to determine the target location might be too vague as there might be two or more patterns with the same scope name. Furthermore, it is not necessary to define a “name” key in a pattern since you may as well just use matches or sub-patterns to define scopes.

  • Replacing/Deleting a pattern: Simply replacing an existing pattern with your own definition; similar to “Injecting before”. Replacing should usually be doable with the “Injecting before” procedure as you can create a match which would make the targetted pattern unable to match anymore. However, it “feels” dirty and matching stuff with no scope just to make the following pattern not match … well, you get what I mean. Encounters the same problems as “Injecting before”.

The latter two can be implemented using a plugin when modifying the existing syntax definition “on the fly” and overriding the default one. The former one can practically be implemented with add_regions() except that it will only color the background.
So, it’s not impossible but it is probably hard to fix the problems and work out some logic for multiple injections.

When there is a dependency management system for Package Control I can imagine this being more useful because the syntax injection plugin can then be required by languages/packages which require these injections.

(Btw, I wrote this post over quite some time because I had many things in mind, sorry if it’s too clustered.)

0 Likes

#8

Thanks for the thoughtful reply. I remain confused though, probably because I’ve about hit my depth with this subject.

It would GREATLY help if you could answer definitively whether ST supports TextMate style syntax injections? I can’t tell if your post presumes I know the answer to that question. I’ve gotten no replies to several forum queries where I’ve tried to find the answer to that (as well as no reply from the developer) so if you know whether TextMate style injections are supported it would be great to have that written down on at least one web page on the entire Internet!

And if it is possible, is there any working example of this anywhere? I haven’t been able to find one.

Back to your analysis, I’m confused as to whether any of your propsed approaches would end up with a more complete / better solution than I have now. It’s unclear whether the potential problems you mention are insurmountable or just hassles?

I’ve tried manually modifying the HTML and JS definitions files (as documented in the HACK SOLUTION comments inside the known_solutions.html file that’s part of the syntax package I linked you to earlier), and from my experiments it does seem this would yield a complete-enough solution to the problem. The only real downside being that it requires forking the number one and two most used syntax files, which is rather in-elegant and not a realistic solution. I do think a simple injection into both those syntaxes (a logical merging done by ST while compiling, not anything that actual changes the contents of any source file) would work fine if it’s the equivalent of the hacks I’ve tried… not sure if those qualify as injecting before, injecting after or replacing/deleting patterns…

0 Likes

#9

No, I don’t know of any functionality like syntax injections that Sublime Text supports natively. It might entirely be possible because loldocs (ST is badly documented) but I highly doubt it.

I was merely brainstorming about the topic, sometimes these things help to inspire others in writing plugins because I don’t really intend to do anything like this myself (because messing with these kinds of stuff is really hacky).

Lucky for you, the default syntax definitions rarely receive an update. And by rarely I mean: mostly not even once a year. Just about recently with the rise of ST3 betas some definitions have been updated due to bugs reported in the release threads, but Jon seems to be busy atm anyway (no new builds).

0 Likes