New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support GitHub-flavoured markdown code fences for highlighting #362

Closed
alanpearce opened this Issue Jul 12, 2014 · 13 comments

Comments

Projects
None yet
5 participants
@alanpearce

I think it would be much better if hugo supported

```html
<h1>example</h1>
`` `

(The extra space is there to avoid GitHub parsing the inner block as markdown)
for highlighted code rendering.

The reason behind this is that a lot of Markdown editors support code fences, but not the highlight tag, so this makes hugo more consistent with other Markdown-renderering projects.

I don't think it would be too difficult for hugo to re-write the example above into the one below before passing it to pygments. What do you think?

{{% highlight html %}}
<h1>example</h1>
{{% /highlight %}}

I'd be happy to try implementing this, although I've only got a little bit of experience with go.

@spf13

This comment has been minimized.

Show comment
Hide comment
@spf13

spf13 Jul 12, 2014

Contributor

If you are using a JS based highlighter than the Github parsing works well.

Since highlight has an external dependency & calls out to an external program, I'd rather that action be pretty explicit. For many if not most people the javascript highlighting solutions should work well.

I'd rather not hijack the current functionality to do something not everyone wants.

Contributor

spf13 commented Jul 12, 2014

If you are using a JS based highlighter than the Github parsing works well.

Since highlight has an external dependency & calls out to an external program, I'd rather that action be pretty explicit. For many if not most people the javascript highlighting solutions should work well.

I'd rather not hijack the current functionality to do something not everyone wants.

@spf13 spf13 closed this Jul 12, 2014

@alanpearce

This comment has been minimized.

Show comment
Hide comment
@alanpearce

alanpearce Jul 12, 2014

Yeah, I'm not interested in javascript-based syntax highlighting. Why not make it configurable instead?

Yeah, I'm not interested in javascript-based syntax highlighting. Why not make it configurable instead?

@spf13

This comment has been minimized.

Show comment
Hide comment
@spf13

spf13 Jul 12, 2014

Contributor

Configurable is possible, but 1. Adds another knob 2. Prevents someone from using both in the same site.

That said, it's not a bad idea and would probably make it easier for some people.

Contributor

spf13 commented Jul 12, 2014

Configurable is possible, but 1. Adds another knob 2. Prevents someone from using both in the same site.

That said, it's not a bad idea and would probably make it easier for some people.

@spf13 spf13 reopened this Jul 12, 2014

@alanpearce

This comment has been minimized.

Show comment
Hide comment
@alanpearce

alanpearce Aug 9, 2014

I think #333 might fix this enough for me, since pandoc supports such code fences in markdown.

I think #333 might fix this enough for me, since pandoc supports such code fences in markdown.

@bep

This comment has been minimized.

Show comment
Hide comment
@bep

bep Oct 20, 2014

Member

After thinking about #565, I've becombe convinced that THIS issue is a great new feature:

  • It should have an option (default false) (yes, a new knob)
  • I suspect very few who use Pygment to code highlight also do client side highlightling (and if they do, they can leave that knob off)

This may seem like a small thing, but for a code intensive blog ("Code Examples Blog"), this is a big thing.

Member

bep commented Oct 20, 2014

After thinking about #565, I've becombe convinced that THIS issue is a great new feature:

  • It should have an option (default false) (yes, a new knob)
  • I suspect very few who use Pygment to code highlight also do client side highlightling (and if they do, they can leave that knob off)

This may seem like a small thing, but for a code intensive blog ("Code Examples Blog"), this is a big thing.

@nathany

This comment has been minimized.

Show comment
Hide comment
@nathany

nathany Feb 28, 2015

Contributor

👍 for code fences and being able to set highlighter = "pygments" or none.

that also opens up the possibility of supporting other highlighters in the future.

Contributor

nathany commented Feb 28, 2015

👍 for code fences and being able to set highlighter = "pygments" or none.

that also opens up the possibility of supporting other highlighters in the future.

@nathany

This comment has been minimized.

Show comment
Hide comment
@nathany

nathany Feb 28, 2015

Contributor

Another good reason for highlighting GitHub style code fencing is that blogs from NetsaCMS or Jekyll also use this format. It's one less thing to change when transitioning, and one less place to result in errors, as I ran into with #933.

Contributor

nathany commented Feb 28, 2015

Another good reason for highlighting GitHub style code fencing is that blogs from NetsaCMS or Jekyll also use this format. It's one less thing to change when transitioning, and one less place to result in errors, as I ran into with #933.

@bep

This comment has been minimized.

Show comment
Hide comment
@bep

bep Feb 28, 2015

Member

I agree.

This could be done fairly cheap by hooking into shortcodeparser.go.

Member

bep commented Feb 28, 2015

I agree.

This could be done fairly cheap by hooking into shortcodeparser.go.

@bramp

This comment has been minimized.

Show comment
Hide comment
@bramp

bramp Jul 3, 2015

Contributor

I attempted to add this support. I started by changing the shortcodeparser.go to return code fence tokens, and then changed the shortcode.go to turn a sequence of backtick, param, text, backtick into a highlight code block.

However, that seemed messy, and meant that blackfriday and shortcodeparser.go was parsing backticks. Instead I'm going to subclass blackfriday.Renderer, to call the highlight shortcode when a code fence is encountered.

Contributor

bramp commented Jul 3, 2015

I attempted to add this support. I started by changing the shortcodeparser.go to return code fence tokens, and then changed the shortcode.go to turn a sequence of backtick, param, text, backtick into a highlight code block.

However, that seemed messy, and meant that blackfriday and shortcodeparser.go was parsing backticks. Instead I'm going to subclass blackfriday.Renderer, to call the highlight shortcode when a code fence is encountered.

@bep

This comment has been minimized.

Show comment
Hide comment
@bep

bep Jul 3, 2015

Member

@bramp yes, that sound more sensible. But it does mean that it will only work for Blackfriday, but I guess that is an OK compromise. Make sure that it is configurable (default off).

Member

bep commented Jul 3, 2015

@bramp yes, that sound more sensible. But it does mean that it will only work for Blackfriday, but I guess that is an OK compromise. Make sure that it is configurable (default off).

@bramp

This comment has been minimized.

Show comment
Hide comment
@bramp

bramp Jul 3, 2015

Contributor

Ok, this was quite easy. It works functional the same to the highlight shortcode. I'll be sending a PR shortly (I need to get my employer's sign off before I can share code). But a couple of comments:

  1. I haven't updated the docs. Happy to do so if requested.
  2. I see there is experimental support for mmark (instead of blackfriday). I can extend this so it works for mmark, but for the moment I haven't.
Contributor

bramp commented Jul 3, 2015

Ok, this was quite easy. It works functional the same to the highlight shortcode. I'll be sending a PR shortly (I need to get my employer's sign off before I can share code). But a couple of comments:

  1. I haven't updated the docs. Happy to do so if requested.
  2. I see there is experimental support for mmark (instead of blackfriday). I can extend this so it works for mmark, but for the moment I haven't.
@bep

This comment has been minimized.

Show comment
Hide comment
@bep

bep Jul 3, 2015

Member
  1. Oh yes. But you can maybe wait with that one, just in case we disagree about property names etc. Just create a PR with the code changes for now.
  2. I would create a pull request for Blackfriday first. Then me and others can test it out and get a feel of it. Then another PR for MM would be a great addition.
Member

bep commented Jul 3, 2015

  1. Oh yes. But you can maybe wait with that one, just in case we disagree about property names etc. Just create a PR with the code changes for now.
  2. I would create a pull request for Blackfriday first. Then me and others can test it out and get a feel of it. Then another PR for MM would be a great addition.
@nathany

This comment has been minimized.

Show comment
Hide comment
@nathany

nathany Jul 3, 2015

Contributor

👍

Contributor

nathany commented Jul 3, 2015

👍

@bep bep closed this in c139c6e Jul 8, 2015

tychoish added a commit to tychoish/hugo that referenced this issue Aug 13, 2017

Add support for GitHub-flavoured markdown code fences for highlighting
This commit adds a new PygmentsCodeFences config option (default false), which if true will allow GitHub style backtick code fences around code, which will then be rendered by Pygments.

For example:

``` language
your code
```

can be used instead of {{< highlight language >}}your code {{< /highlight >}}.

Fixes #362
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment