gma / nesta

File Based CMS and Static Site Generator
http://nestacms.com
MIT License
902 stars 122 forks source link

Markdown h1 with trailing # should be truncated #53

Closed rbq closed 13 years ago

rbq commented 13 years ago

The Markdown bundle for TextMate really loves adding the optional trailing # chars when I press enter after a heading, but Nesta doesn't quite get it and thinks that's part of the title. So my categories ended up like this:

gma commented 13 years ago

Excellent point, thanks for pointing it out. Clearly a bug (though it should only happen for <h1> tags).

gma commented 13 years ago

Fixed by https://github.com/gma/nesta/commit/30f00d6b43858f4dd6a50ae4927f5e625b632a85.

I won't put 0.9.6 out yet with just this in it, but if you want to use it immediately you could update your Gemfile to use the git repo. See http://gembundler.com/man/gemfile.5.html for instructions.

Cheers!

rbq commented 13 years ago

Thanks a lot!

When I looked at the commit I saw that there are some cases that are not covered, namely setext style Markdown headers and multi line HAML. I'm not familiar with the other markup languages but there might be similar cases.

Heading
=======

Heading
-------

%h1
  Heading

What's your opinion about converting the file first and then search the resulting HTML for an <h1> element? Would that be even possible, considering the fact that HAML might contain arbitrary Ruby code that pulls in content from other pages?

gma commented 13 years ago

You're right, multi-line page headings won't work in any of the supported markup languages. I'm not sure that there's a very strong reason to support them though – it'd just lead to a more complicated regex and I'm not sure whether there's much benefit to be had. Do you really want them?

I don't think there's any need to convert a page to HTML and then search for <h1> tags. It'd be a lot slower and Nesta would have to do a lot of HTML processing on every request (it looks at more files than you'd expect in order to work out which articles to link to from the current page).

rbq commented 13 years ago

Thanks for explaining, you're right. I don't really need them and just thought that in theory it would be great to have every possible edge case covered with a clean solution like using the same parser for both tasks (rendering content/determining title).