I think our fandoc syntax should be a plain text format, just like we use on the forum. This syntax was derived from Markdown:
http://daringfireball.net/projects/markdown/
Though I only support a subset here so far. We made two changes though:
Code blocks only require 2 spaces (not 4)
Lists always take precendence over code (so I can indent lists)
Do we allow the full gamut to be used for doc comments? I think we at minimum need to support the following:
Lists (ordered and unordered)
Code blocks
Inline code (backticks)
Inline hyperlinks (automatic links?)
Emphasis (separate bold and italic?)
Also, I had originally voted lists were only indented 0-1 space, so you didn't have to deal with code vs list (you'll find a few errors around here because of this). But Brian insisted on allowing two spaces. If we make the parser smart enough I still don't care - just FYI.
brianSun 2 Jul 2006
I think the parser needs to support stream based pull parser style as well as in-memory DOM style. The stream approach should be used for when translating into HTML for web docs.
andy Thu 29 Jun 2006
I think our fandoc syntax should be a plain text format, just like we use on the forum. This syntax was derived from Markdown:
Though I only support a subset here so far. We made two changes though:
Do we allow the full gamut to be used for doc comments? I think we at minimum need to support the following:
Also, I had originally voted lists were only indented 0-1 space, so you didn't have to deal with code vs list (you'll find a few errors around here because of this). But Brian insisted on allowing two spaces. If we make the parser smart enough I still don't care - just FYI.
brian Sun 2 Jul 2006
I think the parser needs to support stream based pull parser style as well as in-memory DOM style. The stream approach should be used for when translating into HTML for web docs.