Failed to detect fenced code block when there are some parameters after language's name.

[pishen]

We are using an extended fenced code block syntax that there will be some parameters after the language's name.

```scalaFiddle libraries="Java8 Time-0.1.0"
import java.time._

val hour = LocalTime.now().getHour()

println(hour)
```

And this breaks the syntax highlight after this code block. Seems like it is taking the last three backticks in the above example as a beginning of a new code block and highlight all the things after it in a single color.

Any suggestions on how to support this syntax? I can try to tweak it in my emacs but not sure how to start? (Sorry I'm not that familiar with Elisp.)

[jrblevin]

You can edit markdown-regex-gfm-code-block-open. My guess is that the spaces are the issue. Sometimes people enclose the language identifier in braces, like {Emacs Lisp}, when there are spaces. That should work in your case I think.

May I ask which Markdown processor you are using? Does GFM, for example, handle this?

[pishen]

I have set my init.el as

(use-package markdown-mode
  :ensure t
  :commands (markdown-mode gfm-mode)
  :mode (("README\\.md\\'" . gfm-mode)
         ("\\.md\\'" . markdown-mode)
         ("\\.markdown\\'" . markdown-mode))
  :init
  (setq markdown-command "multimarkdown")
  (setq markdown-regex-gfm-code-block-open
    "^[[:blank:]]*\\(```\\)[ ]?\\([^[:space:]]+\\|{[^}]*}\\)?\\([[:ascii:]]*?\\)$"))

but with no luck. Not sure if this is the right way to edit the variable?

We use ornate to process our markdown files.
I'm not sure what do you mean "does GFM handle this"? When editing the markdown on Github directly, the syntax highlight didn't break. But Github's online editor didn't highlight the "language" part specially, it just makes all the stuff between two fences in a single color.

[pishen]

@jrblevin Any further suggestions?

[jrblevin]

Looks like ornate is based on CommonMark, which does indeed allow spaces in the language identifier. It treats the first "word" in the expression as the language name, as in your example.

I'm fine if we allow the regular expression to be more inclusive to allow this, however, it turns out that it's not as simple as changing the regex. The second matching group is also used to parse the buffer for language names, so we need to add a new group to separate the language name (first "word") from the rest and then update the language name parsing code and font lock code.

You may be able to get by for now by just editing the (defconst markdown-regex-gfm-code-block-open line in your markdown-mode.el.