We have a number of hacks to deal with the fact that the tokens "htmlmixed" mode generates for HTML content actually say their mode is "xml". (We care about the mode of individual tokens so as to distinguish JS, CSS, etc. that might be embedded in the HTML).

• TokenUtils.getModeAt() has a hardcoded special case for this
• LanguageManager constructs a fake "html" mode through a back channel (see _setLanguageForMode("html", html) at bottom)
• Language has a special override of the main mode->language mapping just to support this case (see html._setLanguageForMode("xml", html) at bottom -- the only usage of this mechanism).

There are several ways we could fix this & remove those hacks:

a) Make HTMLUtils and other code handle seeing "xml" tokens. Dennis pointed out that much of the functionality there should be callable on any XML content anyway (e.g. getTagAttributes(), getTagInfo()). Cons: tokens remain seemingly confusing; would never be able to distinguish any sort of non-HTML XML embedded inside HTML; we're basically leaving an implementation detail of htmlmixed mode exposed; may break extensions.

b) Change htmlmixed to pull in XML mode by a mimetype alias, which is increasingly becoming the "official" way to reference modes with non-default configurations. So instead of CodeMirror.getMode(config, {name: "xml", htmlMode: true}) it would do CodeMirror.getMode(config, "text/html")). But we'd either have to change all our code that looks for a mode name "html" to look for "text/html" instead, or use "html" as the mime name even though it's not in mimetype format. Cons: requires CodeMirror changes; may involve nonstandard usage of CM's mimetype facility.

For original discussion, see these threads:

https://github.com/adobe/brackets/pull/2844#discussion_r3075488
https://github.com/adobe/brackets/pull/2844#discussion_r3147278