Oh, thanks for the quick reply.

any news on the new parser?

Is this happening at all @vmg ? Seems like everybody still relies on sundown and its bindings.

Can we all help in some way towards this newer standard? Hope to see it soon!

@vmg, is the new parser (we don't even know his name) coming at all?
If it isn't, you would make us a huge favour by unfreezing/undeprecating
Sundown and let life continue as normal. :)

@vmg @jmendeth I second this.

I'm not sure it would be of any use to anyone, but just in case, the original library from which Sundown has been forked is still maintained, and has recently been copied to github at https://github.com/faelys/libsoldout

Cool. :)

Waiting.

Can we un-deprecate Sundown somewhere?

@delvinus Yeah, that's what I was suggesting.
Anybody wants to continue developing Sundown?

@jmendeth I will fork Sundown later today and begin merging PRs that are worthy.

Fork name suggestions would be appreciated.

Sunrise.

@FSX 👍 👍 👍 👍 👍 I CANNOT FIND A BETTER NAME!

@FSX Taken: https://github.com/gampleman/Sunrise

I was thinking either Sunup, Sunset, Moonrise, or Moonset.

But... but... heart broken

Phoenix.

rising from the ashes of sundown? awesome.

To all interested: https://github.com/devinus/hoedown

I have applied PRs that match current Redcarpet functionality but have been languishing in the queue for Sundown and added the official Markdown test suite.

The next steps are:

1. Backport bug fixes and features that Redcarpet has been adding: https://github.com/vmg/redcarpet/tree/master/ext/redcarpet
2. Rename all instances of Sundown to Hoedown and the sd_* functions to either hd_* or hoedown_* (this will break API compatibility, which is a good thing)
3. Reset the version number
4. Add Travis CI automated testing
5. Announce the release
6. Try to convince Redcarpet to use Hoedown so we can both benefit from improvements once again
7. Yell from the rooftops that Markdown isn't dead until there's a better alternative!

Hoedown looking great! I'm forking it.

• Rename all instances of Sundown to Hoedown and the sd_* functions to either hd_* or hoedown_* (this will break API compatibility, which is a good thing)
• Reset the version number

I'll do that. Then I'll update Robotskirt to use hd_.
I'm thinking we could spam broadcast the existence of Hoedown throughout the repo's issues... but... ;)

Backport bug fixes and features that Redcarpet has been adding

So Redcarpet has been keeping his own version of Sundown?

PS. the first thing I'd do is to enable Issues on hoedown.

@jmendeth Issues have been enabled.

I'd like to hold off renaming API functions until I finish backporting all the improvements made in Redcarpet, Houdini, and Rinku. It makes generating and applying edited patches possible.

@devinus Will there be a hoedown organization on GitHub?

I'd like to hold off renaming API functions until I finish backporting all the improvements made in Redcarpet, Houdini, and Rinku. It makes generating and applying edited patches possible.

That indeed makes sense.

@nathany I've created a hoedown org which will host hoedown at some point before we announce. Then we can get binding authors that have switched to hoedown to keep a fork of their bindings on the hoedown org.

@delvinus, can you let me do the backporting as well? :)
I've partly done it with Robotskirt, it'll be easy to do it now.

@jmendeth I have no qualms, but I spent a considerable amount of time last night making a mental map of the things we need to backport. Also, I am trying to keep the original authors attached to the improvements.

We need 2 changes from Houdini, 1 from Rinku, and quite a few improvements from Redcarpet. I may also be interested in a few more PRs from Sundown still. I can go into it more later today, or you can try your hand at it.

My process is creating .diff's from Github, editing them for Hoedown, patch -p1, git commit --author, and, of course, testing.

Houdini has different buffers now (buffer.h and buffer.c). They seem to be derived from libgit's buffers. You'll have to replace Sundown's buffers too.

@FSX I don't think replacing buffer.h and buffer.c would be appropriate for two reasons:

1. Those files are licensed under libgit2's license, GPLv2.
2. We have no idea how they would work for Hoedown. The current buffers are very well tested in many different scenarios already.

Houdini has different buffers now (buffer.h and buffer.c). They seem to be derived from libgit's buffers. You'll have to replace Sundown's buffers too.

You stole my words.

So, if buffer.h and buffer.c are part of houdini, doesn't that mean Houdini is GPL-licensed?

@jmendeth I have no qualms, but I spent a considerable amount of time last night making a mental map of the things we need to backport. Also, I am trying to keep the original authors attached to the improvements.

Then I guess you're better at this task. ;)

Then you'd have to modify Houdini. The buffer API changed a bit.

I just wanted to notify you. :)

I'd keep a file listing the project and the commit we backported changes from.
That when any of these projects makes changes we can easily apply them.

I am running my fork of sundown that adds additional hooks in order to build a Markdown Abstract Syntax Tree (AST). It also includes some preliminary support for source maps.

So my "features request" for a new Markdown parser is:

1. Parse Markdown into an AST (not just render it)
2. Provide source maps

If this would be on the roadmap of the "new parser" I would definitely love to contribute.

@zdne I think that a good practise, but I don't think it fits in Sundown's
architecture. And since Hoedown is a continuation of Sundown...

However, you could still implement an AST renderer.

Nothing is definitive, however--what do you think about it, @devinus?

@jmendeth That is exactly what I have done. I am using the original rendering hooks plus some additional ones I have had to add to build a Markdown AST.

@jmendeth The backporting is complete. These are the bugs I actually discovered in Redcarpet during the process: https://gist.github.com/devinus/30b6df78d96eb9f06d33

Next step is a code reorganization.

This is what I'm going to do:

1. Consolidate all the source files under src/
2. markdown.{c,h} => hoedown.{c,h}, buffer.h => hoedown_buffer.h
3. Prepend all functions with hoedown_*, e.g. houdini_escape_href becomes hoedown_escape_href, bufgrow becomes hoedown_bufgrow

Whoa! That's a lot of changes. Great work!
Here's my thoughts:

• markdown.{c,h} should be left as is.
  This is because its name expresses what part of Sundown/Hoedown is (in that case, the Markdown parser).
  Hoedown is comprised of all the sources, not just the Markdown parsing part.
• Same for buffer.{c,h}. We want to keep things simple, so if the user wants to group Hoedown sources
  he can just put them in a hoedown folder, and then #include "hoedown/markdown.h" (to use the Markdown
  parser) or #include "hoedown/escape.h" (to use just the houdini part).
• About using hoedown_ everywhere (even on houdini) I agree on that.
• I also agree on having all the HTML things in src as well.

@devinus Are all existing licenses (that is, the preambles and license at README)
compatible with the one in LICENSE? I'm presuming so.

@jmendeth Yes.

@devinus Also, why don't we include the whole Houdini set of functions?
I only see escape_html and escape_href.

@jmendeth Sundown/Hoedown only uses escape_html and escape_href

But if we're gonna include and backport improvements from Houdini,
why not let the user benefit from all the other functions?

They can be very useful, especially when writing custom renderers.

@jmendeth: I investigated it, and we can't backport any improvements from Houdini. (There was potentially one, but it requires using Houdini's buffer classes). My gut tells me that if somebody wants another function from Houdini to use in their custom renderer, then they can depend on Houdini

What if we ported Houdini to use our buffer classes? I guess that wouldn't be difficult.

@jmendeth: The one improvement was branch prediction that only applied when using libgit2's buffer class which doesn't apply to Hoedown at all. I may investigate applying some branch prediction around it later.

Hmm... do tell us about that. :)

@zdne Can I ask what static analyzers you used on your fork?

@devinus standard clang static analyzer shipped with Xcode 5. Let me know should you have further questions.

@zdne Thanks, I was looking into using the standalone tool version of it: http://clang-analyzer.llvm.org/scan-build.html

To all those interested:

Announcing Hoedown 1.0.0, a revived fork of Sundown: https://github.com/hoedown/hoedown

I hope to see some of you there!

Any news? :)

There is a community test suite here https://github.com/karlcow/markdown-testsuite

Is https://github.com/jgm/stmd/ the expected heir to the throne?

It should be called now Common Markdown.

@txdv see the footer at the end of the article. It's now CommonMark.

@asgh That's just a spec. They do provide a C99 reference implementation, but I don't think it's meant to be used in production (or maybe it is?).

I want Hoedown to support CommonMark around v4 if possible.

@asgh @jmendeth
I do not believe it is production ready but @vmg looks to be heavily involved in jgm/stmd C implementation.

It is exciting to see all the activity and effort going into CommonMark.

Agreed.