-
Notifications
You must be signed in to change notification settings - Fork 144
Switch to GitHub Flavored Markdown (Redcarpet) + remove scripts/highlight.js along the way #38
Comments
I’m not sure if this is a good markup:
It’s not even proper markup for code blocks. I would rather keep using |
This is the easiest way to enable GitHub Flavored Markdown, and it also produces the cleanest output. Ref. #38.
Agreed, that markup sucks. But that’s an implementation detail. I’ve just tweaked the config file to use Redcarpet instead. Now the output is much cleaner: <div class="highlight">
<pre>
<code class="js language-js javascript" data-lang="js">
<span class="keyword">var</span> … Here’s some default CSS: https://github.com/mojombo/tpw/blob/master/css/syntax.css What do you think? |
Moving my comments from commit 262d83f: Please don’t switch MD parser without discussion. I spent a few really nervous hours today trying to figure out why build task is failing. I don’t want to do this again. I tested a lot of pages with kramdown and some of used features doesn’t work right now (such as The same with Coderay. It’s not the best way to highlight code, from my point of view. I would like to keep Dev.Opera code quality as good as possible. Highlight.js is good enough for this. Let’s just finish the current stage of Dev.Opera development with existing libraries and approaches. |
Yeah, we already agreed on that: #38 (comment). No argument there.
Sorry about that. What was failing exactly? I rebuilt the whole site after switching to RedCarpet and making a small change to markdownline (7c12f92) and didn’t get any build errors after that. (I would have reverted it myself if I saw any kind of error!)
Fair enough, but I’d like to work on switching to Redcarpet in the future, if only for fenced code blocks syntax (switching back to Kramdown ‘broke’ e.g. http://54.213.240.91/blog/opera-19/). So could you please list the issues you were having here so that I can take a look? For example, I have no idea what |
Number of errors related to
But why Redcarpet, why fenced blocks? You need to just indent your code sample by tab or 4 spaces and that’s it — and as it’s indented it becomes much more readable (and also highlighted in code editors). You don’t need to mark you code with language — it will be auto-detected by Highlight.js. Kramdown is really well-documented: quick reference and full documentation. Kramdown allows you to do more flexible code, mixing HTML and MD. And would really like to have more control over Dev.Opera code. To use |
All that is possible with Redcarpet! I ran some tests with the following
Then I compared the HTML output of Reasons to switch to Redcarpet some day
Reasons not to switch to Redcarpet
|
This is the easiest way to enable GitHub Flavored Markdown, and it also produces the cleanest output. Ref. #38.
Why not sundown which is even more faster? Not sure though it Jekyll support non-Ruby parsers. |
The commit message here is a pretty good reason IMHO: vmg/sundown@37728fb Anyway, does it support fenced code blocks? |
Since we’re mostly using code editors for editing articles, is it just a matter of copying code without opening and closing backticks and pressing indent Let’s do it this way: since I have converted a tons of articles to MD and developing content styles and general style guide, I’ll have a look at Redcarpet 3.0 features and how are they aligned with our needs. Kramdown allows us to do much more than any other MD engine, that’s why we’re using it now. |
Also I personally don’t like the idea of code highlighting rendered right in HTML during the build: Output code really sucks.
And
We should have less building things in our process since we’re aiming to a shorter build time. Highlight.js is pretty good at code detection so you don’t have to specify language (I haven’t seen any detection failure). Also it’s not messing up markup with extra divs and nonsense classes. |
You can still do that if you prefer. But IMHO typing a few backticks is much easier, and either way it’s nice to be compatible with GitHub’s syntax (copying from comments/gists/etc. without having to convert the fenced code block syntax manually).
We agree the CodeRay output (first example) sucks. But Redcarpet’s output is really nice. The
It is, though. The only difference is that the extra
I thought tags were the big bottleneck here? Enabling Pygments doesn’t seem to make much of a difference in terms of build times. (Of course, currently all code blocks are marked as text and don’t get highlighting.) Maybe we should move the code highlighting discussion to a separate thread, as it doesn’t block switching Markdown engines. |
hoedown was the sundown continuation, btw. |
Saw on operasoftware/devopera#38 some settings that looked useful.
@pepelsbey I wanted to run this by you. I’ve enabled GitHub Flavored Markdown, which effectively removes the need for the
scripts/highlight.js
file. Now, all the syntax highlighting can be done at build time.All we need to do is use fenced code blocks as described on https://help.github.com/articles/github-flavored-markdown#syntax-highlighting, so that we can (optionally) specify the programming language used for each code block.
The result for an example post that uses this syntax can be found here: http://54.213.240.91/blog/opera-19/
The text was updated successfully, but these errors were encountered: