(Bash and Shell) There is no syntax highlighting for the two. I've seen another issue but didn't seem it got answered.

[dagweg]

The above is the one I'm trying to highlight using marked & I've correctly loaded the language

hljs.registerLanguage("bash", require("highlight.js/lib/languages/bash"));

It doesn't highlight the code even though it works for all other languages.

[joshgoebel]

Just registering a language doesn't highlight anything. You'll need to be much more specific or provide an actual jdfiddle example.

[matanox]

Don't most docs say that it does syntax highlight the code block?
Here's an example where no shell/bash syntax highlighting is applied.

python -m a.b.c --foo --bar 99

The source to the above block is the same as in the original post. The result bears no visible syntax highlighting here, nor in project markdown files.

[joshgoebel]

Any errors in your JS console?

[joshgoebel]

Looks fine on the demo site.

[matanox]

That's a bash script, looks good. I guess that for things like python -m a.b.c --foo --bar 99 which I posted above, it does not actively apply highlighting, as can be seen above.

Or Github are using a different library for formatting here and in general for markdown viewing.

[joshgoebel]

Yeah I think you're wanting a grammar we don't have. Technically --far and -m and even numbers have no real special contextual meaning to the shell unless used in certain contexts (shell arithmetic, which we already support, etc). And if we started highight non-built-in commands (like python) the list would have to be ridiculously long and would never be complete.

If someone made a strong argument for this as part of #2500 as an extension to Bash AND wanted to do the work, I'd listen, but otherwise I'm going to file this under "not a bug" and close the issue.

[matanox]

Yes, you are right an all these assessments, I was wrong to call it bash syntax.

It's probably helpful if a syntax for python argparse syntax was defined, this de-facto syntax is not extremely complicated to define: it's tokenized by spaces, keywords are prefixed with - or -- and tokens not starting with these prefixes are just argument values.

Maybe there are some more intricate cases to that de-facto grammar, but it can be a good start covering probably 80% of the cases, salvaging those long dull lines. What might be the turnaround time until any such "new" syntax definition makes it all the way to Github.com?

I'd take a try at it if it just boils down to defining and testing a syntax, and negotiating what its name would be.

Thanks for your attention.

[joshgoebel]

We have nothing to do with GitHub. I'm not aware they use this library. If you want to contribute a 3rd party grammar, we have docs for that - but that won't get the grammar added to the core library - or GitHub.