Its only job is to define new attribute hljs.LANGUAGE.some_language where “some_language” is a short language identifier suitable to be used as a class name in HTML and CSS. Common good practice is not to define any global variables and do all the work inside an anonymous function:
hljs.LANGUAGES.superlanguage = function() {
var temp_var;
return {
// ...
}
}()
At the top of the file there is a specially formatted comment with meta data processed by a build system. Meta data format is simply key-value pairs each occupying its own line:
/* Language: Superlanguage Requires: java.js, sql.js Author: John Smith <email@domain.com> Contributors: Mike Johnson <...@...>, Matt Wilson <...@...> Description: Some cool language definition */
Language — the only required header giving a human-readable language name.
Requires — a list of other language files required for this language to work. This make it possible to describe languages that extend definitions of other ones. Required files aren't processed in any special way. The build system just make sure that they will be in the final package in LANGUAGES object.
Meaning of other headers is pretty obvious.
The fragment should include various language features. This is used both as an example and a test case. It's usually better to create a synthetic fragment instead of just take a snippet of an existing code because real-world code rarely contains all language features in one place. This fragment is also absolutely not required to actually work or make sense
. Good example are C++ and HTML fragments in test.html.
Then put the fragment into the test.html similar to other languages and test if it's properly detected and doesn't break detection of other languages.
Class reference lives in the file classref.txt. Describe shortly names of all meaningful modes used in your language definition.
If you're a new contributor add yourself to the authors list. Feel free to use either English and/or Russian version.
Send your contribution as a pull request on GitHub.