Extending support for existing languages

[MarkMurphy]

If I wanted to make an extension that offers tag & attribute hinting for SVG I'd ideally be able to un-register ".svg" from the "xml" language and declare a new "svg" language to take over it. (For code hinting specifically, you could do hacks to avoid defining a new language, but ultimately that approach will probably hit a wall).

The more specific formats we add to our languages, the more likely this is to become an issue. But as with my SVG example above, it's possible to hit this issue even on current master.

This issue was initially discovered here: #3029 (diff)

[DennisKehrig]

I now wonder whether a file can actually have multiple languages. An SVG file doesn't stop being an XML file, after all. So maybe languages can inherit from other languages? If a child language defines a file extension that the parent uses, too, the child language is preferred.

[MarkMurphy]

@DennisKehrig Interesting. I can't think of any reason or use case where that would cause a problem. So assuming your proposal would solve the issue at hand, can you provide an example of how that would work in code?

[DennisKehrig]

I'm working on something like this:

    LanguageManager.defineLanguage("svg", {
        parent: "xml",
        name: "SVG",
        fileExtensions: ["svg"]
    })

[MarkMurphy]

@DennisKehrig looks good. Would it make more sense to rename "parent" to "extends" as in oop?

[DennisKehrig]

@MarkMurphy Thanks! "extends" is what I had first, but SciTE highlighted it differently because it's actually a reserved word in JavaScript. So to avoid any issues I wanted an alternative. Seeing how the other keys are not descriptions of what the language does (SVG extends XML), but what the language has (a name, a mode, a comment syntax, ...), "parent" seemed to fit in great, especially since it then goes along with a _setParent method.

[njx]

Reviewed. Marking low priority, but since @DennisKehrig already has a potential solution, @peterflynn will review when he has a chance.

[peterflynn]

Closing -- in Sprint 38 it's possible to unregister a file extension and register it to a new language, and as noted above this can also be resolved by just writing a code hint provider that registers for the built-in "xml" language but only responds when in SVG content.

In the future we may start seeing use cases where solutions like that aren't adequate, but in the year since we originally raised this question we haven't hit any yet, so I think it's safe to close this and reopen or refile later when/if we run into it.

(See also further thoughts here: #3052 (comment))