Axel, I agree we need to keep AsciiDoc evolving and we need to start thinking about a standard that a) encourages multiple implementations and extensions and b) taps into the adoption of Markdown.
I think the recent announcement of Standard Markdown (later renamed to Common Mark) makes it pretty clear that Markdown itself is quite resistant to any sort of "merge". From what I can tell, they don't really want to give AsciiDoc the time of day and have avoided any sort of dialog thus far. (I'd love to be proven wrong and I'm always open to chat about it). The best strategy for the AsciiDoc community, IMO, is to recognize that we have something great and to make it the best we can. Adoption will happen if it's deserved. AsciiDoc Python is one implementation, Asciidoctor is another. But it's hard to have more until we start nailing down what AsciiDoc is (most importantly, a grammar). Eventually, we need multiple implementations just like Markdown. Only, in our case, we can avoid all the in-fighting and divergence because we can learn from Markdown's mistakes. It will take time, but we can start down that path now. While there are parts of the Markdown syntax that we can adopt to ease migration (section titles, blockquotes, horizontal rules, fenced code blocks, etc), there are other parts of the syntax that I think are poorly done and we should avoid, like the link and image syntax. I'm in agreement that for every shorthand in AsciiDoc, we should have a formal, named equivalent (ideally following the <name>:<target>[<attributes>] pattern) so you can type your document using only the named constructs (i.e., pass:[] instead of $$). I posted my thoughts about where I think we should head with AsciiDoc in the AsciiDoc vs Asciidoctor thread: https://groups.google.com/d/msg/asciidoc/6yKQeTeM1B4/xVp6jBWXp7QJ In summary, I think we can leverage some of Markdown's strengths, but the focus should be on defining a standard and encouraging multiple implementations. I've worked with many standards in Java, so I feel like I have a good understanding of the role a standard should serve. I've also seen how much innovation a standard can bring. I'll say this final point many times. A standard is not a solution. A standard gives us common foundation and lingua franca so we _can_ extend and innovate. And it absolutely does not have to be perfect. -Dan On Tue, May 6, 2014 at 2:49 PM, Axel Rauschmayer <[email protected]> wrote: > I absolutely love AsciiDoc. Basing it on DocBook was a brilliant idea and > gives it a solid foundation. > > I have a few radical ideas for the next version of AsciiDoc (“AsciiDoc > 2”). If you would, please hear me out and tell me what you think: Which of > them work and which of them don’t? > > Main idea: I’m using both Markdown and AsciiDoc. When I work with the > former, I miss AsciiDoc’s power. When I work with the latter, I miss > Markdown’s broad support. That got me thinking: why not merge the two? They > are so similar already. The current situation is as follows: > > * Markdown is immensely popular and used for many projects: for > documentation on GitHub, for blogging, for book publishing (LeanPub), etc. > On the other hand, its scope is limited, it is not well suited for books > and there are many competing and incompatible extensions (GitHub-flavored > Markdown, Kramdown, MultiMarkdown, Maruku, etc.). > * AsciiDoc has everything that Markdown is missing. > > Merging the two would give people the best of both worlds: For simple > things, one could use the widely-supported Markdown. For books (etc.) one > could profit from AsciiDoc’s extensive experience with sophisticated > projects. Given that there is no clear standard for a “Markdown for books”, > AsciiDoc would be a convenient upgrade path for Markdown and could become > very popular. Or rather, even more popular. > > Given that there are a few incompatibilities, I’m not sure how to best > merge Markdown and AsciiDoc. One option is to maintain AsciiDoc 1 and > AsciiDoc 2 separately. > > > A few more wishes for version 2: > > * Improve the parser. It feels like it could be much faster. And more > consistent. For example, escaping is currently context-sensitive (you have > to take into consideration whether you’ve escaped somewhere else in the > same line), which is unpleasant and user-unfriendly. I also think backticks > should work with suffixed apostrophes. Currently, I need work-arounds such > as ++foo++’s, beacuse `foo`’s doesn’t work. > > * Support indented paragraphs. These are especially handy for presenting > math. > > * Improve the support for math. Especially latexmath:[] is brilliant, but > it prevents you from using the dollar sign elsewhere in the HTML generated > directly by AsciiDoc. > > * Possibly: more named constructs. Beyond the basics, I find ASCII symbols > hard to remember. Named constructs, such as named blocks, work better. > > > What do you think? Do these ideas make sense? > > -- > You received this message because you are subscribed to the Google Groups > "asciidoc" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/asciidoc. > For more options, visit https://groups.google.com/d/optout. > -- Dan Allen | http://google.com/profiles/dan.j.allen -- You received this message because you are subscribed to the Google Groups "asciidoc" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/asciidoc. For more options, visit https://groups.google.com/d/optout.
