Can you set multiple grammar/autocomplete rules for a filetype?


I’m trying to use Atom for writing Markdown files, which contains some raw HTML. Since I’m not an expert in HTML, I tend to constantly forget tags and their parameters, so I really like the features of the builtin autocomplete-plus for HTML, which lets you see the parameters, and also places them with tab.

Now onto my problem: I’m editing a Markdown file, and I would like the HTML autocomplete to turn on and help me with the tags when I’m writing HTML in the file. I can achieve this by setting the file language to HTML, but then I lose all Markdown syntax highlighting and every function from the Markdown plugins.

Is there a way I can enable both HTML and Markdown autocomplete and syntax highlighting for Markdown files?

Also, I have installed the language-markdown package, which says in the readme that it supports raw HTML if I have language-html grammar enabled. How can I enable that grammar for Markdown files? I have tried editing both the language-markdown files and the autocomplete-plus config files, but with the prior I didn’t manage to achieve anything, and with the latter, I couldn’t even find the config files. (Also, I’m not even a beginner when it comes to tinkering with Atom, so it is more than plausible that I messed something up)


Yes, Atom is capable of supporting multiple grammars or autocomplete providers on a single file type. You can see this in pretty much every grammar available since the language-hyperlink grammar injects itself into every other grammar to highlight URLs. Autocomplete providers have a similar system.

The thing is that there is nothing you, as the end user, can do to “enable grammar X for language Y”. Either the grammars and autocomplete providers are designed by their authors to work the way you want or they’re not. If the maintainer for language-markdown says that it should work so long as language-html is enabled, then you should be good because language-html is installed and enabled by default in Atom installations.


OK, thanks for your answer. Then it looks like the only way to make it work is to create my own language package, or modify the language-markdown package to enable autocomplete for html. Are there any guides or examples for tasks like this? What I found are majorly about converting or using TextMate grammars, but I feel like what I need is more Atom specific.


It’s not terribly hard to create your own language package, but I wouldn’t recommend it. I think your problem can be solved more easily.

From the looks of the autocomplete package, it gets triggered whenever the cursor is inside the selector .text.html, but if you look at the HTML tags on markdown documents, you will see that they have no .text class. There are a few possible solutions I see.

  1. Fork autocomplete-html and change the selector in the file I linked to .text.html, I just did this and it works like a charm. The problem(?) is that then you have an unsupported change to a core package. The question mark is because this particular package is not one that gets frequent updates (or any, really, possibly until HTML6), so out of all the core packages, I can’t see this one causing any trouble.
  2. The method onDidChangeGrammar() can be used to watch when a grammar is change and execute code, so in theory, you could write a function in your to subscribe to a grammar change and then inject the .text class into any elements with the .html class. I have no idea if this would actually work and I can’t test it because the documentation is not sufficiently verbose to be of help to me with my limited understanding of callbacks.
  3. Fork @burodepeper’s language-markdown and change its patterns so that anything matching HTML winds up inside text.html before it refers to the HTML package. This might actually be a good potential pull request (so that other people can use HTML autocomplete too), but would be a more stressful version of #1 for you as the user. It occurs to me that this could mess up severely at unspaced math equations, so probably not.

tl;dr, solution #1 is against what @leedohm would tell you is good practice, but the number of problems it could potentially cause are negligible unless something in the autocomplete provider API changes and all autocomplete packages have to upgrade.


I like solution #1 best, but ideally with the selector as a setting in the package config so the autocomplete isn’t forced upon users, while at the same open to any other grammar. Perhaps @leedohm can assist with pushing the PR through.

If solution #1 proves troublesome, solution #3 seems the logical successor. I don’t know if it is as easy as it is made out to be though. language-html is included, but there’s no matching in language-markdown that would allow things to be wrapped in text.html.