*slaps her forehead*
@mike.bronner I’m so stupid… you’re right, I’m so sorry lol
It seems that you guys are reading my mind because I was also going to suggest something that @kopischke has just proposed!
Understanding now that @mike.bronner is running, at the same time, the PHP-HTML ‘built-in’ syntax highlighter, plus the Blade extension, and plus his own genealabs/intelephense extension, the original problem he described is due to the fact that the three extensions are not ‘active’ at the same time.
I actually faced that when starting to toy around with the Go extension. The one I had for Coda 2 worked quite well, but nothing was available for Nova. So I tried my best to replicate the syntax highlighting (but the actual format is quite different, so it took many trials & errors). I then noticed that I wasn’t getting even the most basic completions. Ok, so I added a completions XML file and registered the extension with ‘completions’ as well. But I was missing some nifty extra features, which only a Language Server could provide. Sure thing, I just added support for the Language Server (at a time when Nova still has many limitations in communicating with it). In the meantime, I noticed that my Go templates were being rendered as text-only. Bummer! Go templates are inspired on Smarty (or Blade), and there was a Smarty extension available, so I tried it out — but I couldn’t have both Go and Smarty running ‘simultaneously’. Ok, no problem, I copied the Smarty language extension, tweaked it a bit, then added it to ‘my’ Go extension… and so on. Recently I had to add a completely new syntax highlighter, this time for Go imports, which are stored inside go.mod files… so, aye, another syntax added… and this, of course, will go on and on…
And in the meantime, the GoTools extension was added to the library — because ‘my’ extension didn’t call any external commands to automate workflows. So that developer had no choice but to develop his own solution — but then he lost the syntax highlighting from ‘my’ extension… which meant grabbing ‘my’ syntax highlighting and add it to GoTools, and register it as a ‘language extension’ as well. It means that, right now, if you wish to use the powerful enhancements of a Language Server, you have to use ‘my’ extension; but if what you ultimately need is a set of post-processing tools, then you’ll have to pick GoTools instead. You can’t get both. As time passes, I’ve done substantial changes on the syntax highlighter — meaning now that ‘my’ extension is a bit better at doing syntax highlighting than GoTools; the developer will now have to pay attention to what I’m doing on my own, and, as soon as I release a new version of the syntax highlighting, he’ll have to copy it over to his own extension to keep both in sync… sure, we might get an agreement to mutually exchange the syntax highlighting XML file as soon as any of us updates it… but now imagine that someone, finding that ‘my’ extension does a rather poor job of dealing with Completions, decides to write his own Completions file and grabs the syntax highlighting XML from either of us. Now we’d have three different extensions, all providing different goodies on Go files, but all need to be installed simultaneously but only one can be ‘active’ — so there is no way to get the full functionality of all three at the same time. Unless, of course, we all agree to pour our efforts into a single, unified, mega-extension. But then someone else might develop a fourth extension to provide Snippets… you see how quickly it gets out of hand!
In @mike.bronner’s case, it seems that the ‘solution’ is basically grabbing the syntax highlighting from one of the PHP extensions (either the built-in one, or advanced PHP, or any other) and include it with his integration with Intelephense. Again, every time the syntax highlighting/completion files change, he’ll have to manually copy them over…
My original idea was simply to allow different extensions to register the same language, and get Nova to activate all of them at the same time, if they don’t ‘overlap’ — so you could have an extension providing syntax highlighting, another calling external CLI tools for post-processing, another integrate with the Language Server, another adding optional, additional syntax highlighting for Go-related files which are not Go source files, and so forth; so long as there was no overlap, this should work.
But after reading your suggestion, it makes so much more sense to have a way to ‘inject’ additional functionality in existing extensions. One thing that I’ve struggled with was how to deal with the auto-documenting tools that already exist for Go. These search for special formatting on the comments, like so many other auto-documenting tools on other languages. The Coda 2 syntax highlighter already added such functionality — at least, to a degree. The Language Server is supposed to also be ‘auto-documentation-aware’, but I’ve not even started looking at that yet. The point here is that I might not need to create a completely new mega-extension that does ‘everything’. I just want to have something working in tandem with the existing extension, but allow a new extension to focus exclusively on the auto-documentation aspects. The same also applies to TODOs, BUGs, etc. And probably it would be the ‘right’ approach for dealing with different templating engines which are a meta-syntax on top of an existing language — such as Blade/Smarty templates deployed on PHP. I imagine that similar strategies would also work best for dealing with CSS, since so many different tools deal with CSS generation.
So, in other words, what we’d like is some sort of ‘sub-extensions’, or ‘co-extensions’, that might override some functionality or add some more functionality on top of an existing, active extension (built-in or installed from the Library).
The closest I’ve seen so far is the pragmatic approach used by @dennisosaj for advanced PHP. Some of the features of his extension require theme developers to add a few more rules to fully support his extension. He documented those ‘requirements’ well enough, and they’re very easy to implement, so a handful of theme developers have already tweaked their own themes to be ‘advanced PHP-compliant’. Because themes are conceptually different from language extensions, even if they all come from the same source, this approach works — when using PHP, you can switch on advanced PHP for some extra juice, and, if your current theme enables those extra goodies, you’ll get even more ‘bang for the buck’, so to speak. This avoids the need for @dennisosaj to basically replicate all themes out there and include them with his own extension — a daunting task (and also a very un-pragmatic approach).
So, aye, I guess that this ought to become a Feature Request — implement ‘sub-extensions’, or ‘child extensions’, or an ‘injection’ functionality (because in some cases it might be necessary to ‘inject’ code not only on one ‘parent’ language extension, but on several). How exactly to do that in the simplest way possible — without having to redesign the whole extension mechanism from scratch, potentially creating a ‘Nova 2’ which would break all existing extensions! — is certainly a challenge; but I totally agree that this is the way to go.
Think WordPress plugins 
I can easily imagine scenarios where the same filename extension is used by completely different languages (it’s not usual, but nevertheless possible) — which one will be picked? Is it First Come, First Served?