@calini Our sample file is rendering without a problem and I can't reproduce this problem. Do you have more details?

Not really, since I have not tinkered with the configuration, especially nothing related to code highlighting/rendering. I can provide links to places where it shows up: link on my website, link to .md source

Thanks! That's helpful. Will have an investigate!

Hmmm, it looks fine in this snippet. And it worked fine when I used rougify.

I noticed that the symbol used for the code fences differs between Go and the other languages. If you use ~ or ` for all three are the results the same?

Hmmm. I cloned the Git repo and the problem seems to be the way in which the HTML is being output.

The default rendering puts all tokens in their own <span> tags. With Go code, the newlines in the code block are also wrapped in these tags and that's causing them not to display. If you look at the HTML for the Java and C code, you can see the newlines there are outside the <span> tags.

Not sure how to fix it yet but I think we're getting closer.

It just occurred to me that newlines are significant in Go in a way they aren't in Java and C. The fact the lexer is matching these newlines explicitly is probably what's causing the difference.

The 'problem' is here. Other lexers tokenise whitespace as Text whereas the Go lexer uses Other.

This becomes an issue when it's being rendered as Text tokens are not wrapped in tags at all. This is important because of this CSS rule.

I'm not sure which is correct; arguably a newline at the end of a statement isn't really 'text'. Plus the problem is in many ways the CSS rule; you can 'fix' the rendering problem by just changing how it works. What do you think?

I could just fix it in my fork but that means whoever is pulling a theme that uses Rouge will deal with the same thing. Should I fix it and do a pull request on it?

I had a look at the description of the tokens in the wiki and Other is described like this:

Token for data not matched by a parser (e.g. HTML markup in PHP code)

Pygments has the same description.

To my mind, that's not an accurate description of whitespace in Go. That makes me feel confident that changing the token to Text is the proper approach (there is actually a Text::Whitespace token but I think at this stage it's enough to have the Go lexer be consistent with other lexers).

I'll update and submit a PR.