Live data from Hacker News

GitHub pages is now running Jekyll 3

github.com

111–119 of 119 posts

Re: GitHub pages is now running Jekyll 3

#111
post #97
post #27

OK, a standard dialect of Markdown. In the beginning was RUNOFF from MIT, which originally had about the power of Markdown. More features were added, and it became nroff, then troff, the ditrofff, and macro systems were added on top of it. It became too hard to use for casual work. Then there was TeX, which was a saner approach to what troff did. Macro systems were added on top of it. It became too hard to use for ca…

That's basically a sample size of n=5 from which you inferred that "has macros" and "is popular" are causally linked, which should get you expelled from every statistics department in the world ;) My guess is that various syntaxes for doing basically the same thing fade in and out of popularity randomly and for the most part independent of their feature set, just as different ways of covering the body with cloth fade…

No, no, I don't claim that having macros is required for popularity. I claim only that the growth pattern of "simple" markup languages is to add features which make them no longer simple. At that point, new simpler markup languages appear, and the cycle repeats.

Re: GitHub pages is now running Jekyll 3

#112
post #81

Earlier quoted context omitted.

That's why I prefer ReST. More powerful syntax out of the box with a standard extension scheme so you don't end up with the mess of all the different incompatible Markdown implementations. With the internal structure exposed as an XML format (rst2xml) it is easy to transform documentation into a wide variety of formats that docutils or Sphinx don't handle directly.

A lot of that sounds good but you lost me at XML.

The XML dump exposes the parsed document structure so you aren't forced to use the usually limited output options of the native ReST or Markdown tools. Instead of generating the lackluster output from latexpdf you can transform from ReST -> Docbook -> XSL-FO -> PDF, or other targets like HTML, WordML, DocX, or ODF. Manipulating documents is what XML is really for. It gets a bad rap because it is abused so much for storing data, scripting, and other silly stuff.

Re: GitHub pages is now running Jekyll 3

#113
post #93

Recently tried Hugo. The speed is amazingly fast. Much much faster than jekyll.

FYI: I've put together a static site showcase called Stay Static [1] that builds the same site (w/ pages, posts and links) for easy comparision with Jekyll, Middleman, Hugo [2], etc. Hugo is great. The Go template language is somewhat unconventional and does not yet support nested layouts (as do Jekyll, Middleman, etc.), for example. Cheers. [1] http://staystatic.github.io [2] https://github.com/staystatic/hugo

nice. the theme looks good too. i think will fork it to rebuild my site.

Re: GitHub pages is now running Jekyll 3

#114
post #68

Earlier quoted context omitted.

No way. Asking for free stuff when you don't need it or can buy it cannot be respectful.

> non-enterprise gitlab.com users No one was asking for it to be free. Currently it's tracked as a feature for enterprise users. They have 3 paid plans for non-enterprise users, and I'm certain many of those non-enterprise folks would love it.

I'm sorry. My comment was intended as a joke.

Re: GitHub pages is now running Jekyll 3

#115
post #91

Earlier quoted context omitted.

But I want to strip newlines from .md files.

That's why significant end of line whitespace is a terrible design feature. You can't see it. It might get deleted accidentally. There were some systems back in the DOS/early UNIX era which had significant EOL whitespace. Spaces at the end of a line are still significant following a "\" in shell files. Some early word processors under DOS had significant whitespace at EOL, but tended to display something like a parag…

MD could have been fine if it were the beginning of the line. "Any indentation without a blank line above is BR"

It would make multiple repeated BRs difficult, though, but you probably shouldn't be doing that anyways.

Re: GitHub pages is now running Jekyll 3

#116

Earlier quoted context omitted.

For what it's worth, GitHub Flavored Markdown changes this to be more TeXy: any newline in text renders as a , and you add an extra blank line to denote a paragraph break.

Unfortunately that means that you absolutely need to enable word wrap in your editor, people cat-ing your readme on the shell will see ugly mid-word wraps, etc. Not the end of the world or anything, but somewhat inconvenient.

That sounds like a failure of cat more than a failure of markdown. There isn't a command-line argument for cat to break long-lines at the last whitespace of the line instead of mid-word?

Re: GitHub pages is now running Jekyll 3

#117

Earlier quoted context omitted.

For what it's worth, GitHub Flavored Markdown changes this to be more TeXy: any newline in text renders as a , and you add an extra blank line to denote a paragraph break.

Unfortunately that means that you absolutely need to enable word wrap in your editor, people cat-ing your readme on the shell will see ugly mid-word wraps, etc. Not the end of the world or anything, but somewhat inconvenient.

[deleted]

Re: GitHub pages is now running Jekyll 3

#118
Frankly, Github did a very poor job at communication this breaking change.

I only recently discovered that most of my post got broken.

Apparently it's no longer legit to use "#Title", you need to "# Title" (and god knows what else).

Linking is broken too - in Jekyll 2 there was no difference if a URL ended in "/" or not - you were just taken to the page, now this is a massive, although fixable pain (see https://github.com/jekyll/jekyll/issues/4440)

As a result my site experienced 500% drop in organic search referrals from Google.

I got no single email from then announcing this change. Very unhappy with how github handled it.

Post reply on HN