When assigning a language to code blocks, I often use js to mean javascript . This is not recognised by the markdown engine(?) these forums use, so I am forced to go back and replace it with javascript . Having js as an alias would help a lot, especially as it is valid in other markdown places (like GitHub).
It’s also fairly unambiguous, as JavaScript is almost always shortened to JS when the name will be used frequently.
Pretty sure the syntax is specified by highlight.js, not markdown. Per How to use highlight.js you need to specify the language, which the library calls javascript, not js.
FWIW, I’ve made the same mistake with C++. I thought it would be c++, not cpp
Thanks for the pointer. I followed the link, and it says
The list of supported language classes is available in the class reference
The class reference it links to has a table of supported languages, and recognised keywords to select each one. I believe the “bottleneck” is happening on the discourse side, where it’s only passing a limited subset of language keywords to Highlight.JS.
In fact, it would be great if all the supported keywords were allowed, as some look quite interesting.
FYI, it has js for JavaScript, and c++ for C++. So I think this is definitely worth looking into.
Ooh, interesting. Perhaps we only pull the first alias for each language? An engineer would know more.
It is intentional that we do not. Including all languages affected performance. Admins can configure the highlighted languages on their site via the highlighted languages site setting. I’ve included the languages that are enabled here on Meta for you below:
OK, what should I do from here? Raise an issue on the repository, or let a discourse staff member take over?
You’ll need to wait for one of the engineers to see this (we track issues here, they’re disabled on Github) Keep in mind it’s late Friday (or even Saturday) for most of the team, so this may not be seen until Monday.
On a whim I just added js and c++ to the highlighted langugages site setting here on Meta and that appears to have done the right thing:
js:
(function() {
var ps = require('preload-store').default;
Discourse.CDN = 'https://d11a6trkgmumsb.cloudfront.net';
Discourse.BaseUrl = 'meta.discourse.org'.replace(/:[\d]*$/,"");
Discourse.start();
Discourse.set('assetVersion','367b6f2f4971d9a8e8f7c712cd0de182');
Discourse.Session.currentProp("disableCustomCSS", false);
Discourse.HighlightJSPath = "/highlight-js/meta.discourse.org/7b8d9ac1f45289d14ec6dc64f8a0891c61ec77a5.js";
Discourse.S3CDN = 'https://d11a6trkgmumsb.cloudfront.net';
Discourse.S3BaseUrl = '//assets-meta-cdck-prod-meta.s3.dualstack.us-west-1.amazonaws.com';
c++:
(function() {
var ps = require('preload-store').default;
Discourse.CDN = 'https://d11a6trkgmumsb.cloudfront.net';
Discourse.BaseUrl = 'meta.discourse.org'.replace(/:[\d]*$/,"");
Discourse.start();
Discourse.set('assetVersion','367b6f2f4971d9a8e8f7c712cd0de182');
Discourse.Session.currentProp("disableCustomCSS", false);
Discourse.HighlightJSPath = "/highlight-js/meta.discourse.org/7b8d9ac1f45289d14ec6dc64f8a0891c61ec77a5.js";
Discourse.S3CDN = 'https://d11a6trkgmumsb.cloudfront.net';
Discourse.S3BaseUrl = '//assets-meta-cdck-prod-meta.s3.dualstack.us-west-1.amazonaws.com';
(that said, I can certainly agree that we SHOULD be pulling in the synonyms and allowing those for enabled languages)
Not necessary, the workaround is trivial, so use the workaround.
Most sites use auto highlighting 99% of the time so this is a non-issue:
```
versus
``` blehI don’t think the auto highlighting is working then. Even on this site, observe the following
No language name:
let x = 10;
function root(n) {
return Math.sqrt(n);
}
console.log(root(x));
javascript as language name:
let x = 10;
function root(n) {
return Math.sqrt(n);
}
console.log(root(x));
There is a difference in appearance, indicating a different set of rules is being applied (even though both are identical JavaScript). And it’s not just these two language that would benefit from allowing synonyms; there are quite a few that offer alternative naming.
It appears to be due to some rules trying to undo certain highlighting on Javascript. It’s different because the top is marked as hljs javascript versus the second which is lang-javascript hljs.
.hljs-keyword,
.javascript .hljs-title,
.nginx .hljs-title,
.hljs-subst,
.hljs-request,
.hljs-status {
color: #333;
font-weight: bold;
}
.javascript .hljs-title,
.lisp .hljs-title,
.clojure .hljs-title,
.hljs-subst {
font-weight: normal;
}
If we wanted a special case it belongs here
But making auto work better is probably a better first approach, if your site is all about js you can just default to it
I originally posted this on the Atom forums, and was directed here. Atom package development is heavily JS orientated, but also has a lot of CoffeeScript (that’s in the process of being phased out).
Oh why not suggest they make the change to default code lang to javascript? That is the vast majority of code pasted in anyway (and you can override per snippet where needed)
Also they could cut down on the languages supported to make auto detection more reliable.
That said, I would like to investigate with https://github.com/isagalaev/highlight.js/ why that snippet is not auto detected properly, perhaps open an issue there.
One minor issue with making js a shortcut for javascript is that I would assume you would also want cs to be shore for coffeescript but that would clash with c sharp.
I believe coffee is the normal shortcut for CoffeeScript (probably for that reason). Additionally, the Highlight.JS docs I linked to still consider cs to be C#.
I don’t know anything about the internals here, and didn’t understand the workaround that was supplied above (I assume any maintainer would though), but I would have thought just adding js and c++ to the list of languages passed to Highlight.JS would work. No special handling should be needed, as the docs list them as recognised aliases.
Oh if it is a recognized alias then sure we should support all aliases defined in highlight. Which brings us back to https://meta.discourse.org/t/add-js-alias-for-javascript/81298/11?u=sam which would need some tlc.
If you are feeling brave why not try hacking on it. First step if finding a list of all the official aliases.
This appears to be the complete list of aliases for languages.
http://highlightjs.readthedocs.io/en/latest/css-classes-reference.html#language-names-and-aliases
I’m not familiar at all with the discourse repository though, so I don’t think I can contribute much beyond this.
I can see this in the source and lots of these we would like to support docker is much nicer than dockerfile for example.
Repository search results · GitHub
Putting a pr-welcome on this.
The only simple way of doing this would be to send a different var to pretty text with list of allowed aliases instead of allowed languages.
It is being detected properly, it’s just applying different CSS classes:
The hljs <span> elements are identical, only the coloring differs.