Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Browse files

Let the world know that Sundown is deprecated

commit 37728fb2d7137ff7c37d0a474cb827a8d6d846d8 1 parent fc97fc3
@vmg authored
Showing with 10 additions and 0 deletions.
  1. +10 −0 CONTRIBUTING.md
View
10 CONTRIBUTING.md
@@ -0,0 +1,10 @@
+Contributing to Sundown
+=======================
+
+Do not.
+
+Unfortunately, Sundown is currently frozen as we're working with the Reddit, StackOverflow and Meteor developers to design a formal Markdown standard and parser that will supersede Sundown in all these websites (and in GitHub, of course). Our goal is to deprecate Sundown altogether before the end of the year.
+
+The new parser will be smaller, faster, safer and most importantly, more consistent.
+
+Please stay tuned.
@txdv
txdv added a note

new line

@rudyryk
rudyryk added a note

Any news? :)

@rudyryk Well, we started a fork called Hoedown, it's pretty mature now, we'll soon release version 3! :D

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

80 comments on commit 37728fb

@FSX

The world is ending!

@Tuckie

Uniformity?! With Markdown?! Across websites?!
I will assume hell is freezing over, but in the meantime, somewhere to follow the status of this collaboration would be fantastic.

@naggie

I hope the new markdown parser will be github flavored. Is there a public project anywhere?

@lepture

@FSX 10 days left.

@funchal

@vmg Looks like a good initiative. It's super hard to get around with so many so-called flavors of the Markdown format. I think the source of the problem for end users is that people call their slight modifications "flavors" of something pre-existing, instead of naming it with a different name clearly indicating that it implements a different (though similar) wiki syntax.

I also hope you guys can find time to write down a quick reference or some documentation of the sundown/redcarpet flavor of Markdown. Have a look at the one in the kramdown site, it's really good.

@txdv

Damn it, I should have read this earlier.

@txdv

@vmg is there a collaborative site available? A repo or something? To follow the development?

@vmg
Owner

Nope. I'm on holidays! Happy holidays everybody! Now go party!

@txdv

No, i go code.

@jmendeth

:christmas_tree: @vmg

Our goal is to deprecate Sundown altogether before the end of the year.

Well, according to the root NTP server, you now have exactly* 12 hours left.
Please, publish! :)

$ date -u
Mon Dec 31 12:00:00 UTC 2012

* Yes, I know that's actually less than 12 hours.

@naggie

lol!

@txdv

time is up, where is the code

@jmendeth

@txdv okay, let's calm down everybo...
GIVE US THE CODE!! ;)

@jmendeth

I've been checking out this page every 5 minutes,
because I was so lazy to program a robot to check it for me...

@ibigbug

However why so many people focus on this project?

@jmendeth

Because having a solid, flexible, secure Markdown parser is a must-to
on a decent web application. Also, when you know something good is
gonna appear, you become excited. And impatient.

@ibigbug

So sad

@jmendeth

@ibigbug Why? Markdown is a nice
and accepted standard. Now, the parser
itself is also being standarized.
How is this bad?

@jmendeth

OK, we all know that @vmg's work in LibGit2 is awesome,
but we would really love a response in respect to that new :gem:.

My Hubot is pretty tired of checking this repo one time and another,
without seeing a single change.

@vmg
Owner

I'm sorry guys, I'm not webscale. The new parser will come on its own schedule, when I find time to dedicate to it. It used to be a priority, but now I've got things on my plate that are more important. Keep using Sundown meanwhile. It's still fast and secure.

@jmendeth

Oh, thanks for the quick reply.

@txdv

any news on the new parser?

@zdne

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

@nishantmodak

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

@jmendeth

@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. :)

@zdne

@vmg @jmendeth I second this.

@faelys

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

@FSX

Cool. :)

@Honghe

Waiting.

@jmendeth
@devinus

Can we un-deprecate Sundown somewhere?

@jmendeth

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

@devinus

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

Fork name suggestions would be appreciated.

@FSX

Sunrise.

@jmendeth

@FSX :+1: :+1: :+1: :+1: :+1: I CANNOT FIND A BETTER NAME!

@devinus

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

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

@jmendeth

But... but... *heart broken*

@FSX

Phoenix.

@nathany

rising from the ashes of sundown? awesome.

@devinus

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!
@jmendeth

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.

@devinus

@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.

@nathany

@devinus Will there be a hoedown organization on GitHub?

@jmendeth

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.

@devinus

@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.

@jmendeth

@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.

@devinus

@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.

@FSX

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.

@devinus

@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.
@jmendeth

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

@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. ;)

@FSX

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

I just wanted to notify you. :)

@jmendeth

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.

@zdne

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.

@jmendeth

@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.

@jmendeth

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

@zdne

@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.

@devinus

@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
@jmendeth

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.
@jmendeth

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

@jmendeth

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

@devinus

@jmendeth Sundown/Hoedown only uses escape_html and escape_href

@jmendeth

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.

@devinus

@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

@jmendeth

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

@devinus

@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.

@jmendeth

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

@devinus

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

@zdne

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

@devinus

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

@devinus

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!

@rudyryk

Any news? :)

@JCMais

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

@asgh

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

@txdv

It should be called now Common Markdown.

@jmendeth

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

@jmendeth

@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.

@styfle

@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.

@jmendeth

Agreed.

Please sign in to comment.
Something went wrong with that request. Please try again.