On 10 December 2012 20:49, Dan Allen <[email protected]> wrote: > I'd like to share with the AsciiDoc community that there is an effort > underway to create a cleanroom port of AsciiDoc to Ruby, named asciidoctor > [1].
Thats interesting, pity its Ruby :) > > This AsciiDoc port is close to being usable for the most common syntax, but > still has a long way to go for complete compatibility. But give it a chance, > it's a start. Indeed and full marks to the devs for honesty about the status, "need a high tolerance for bugs" :) > > Why is this good? If the Ruby language itself can serve as evidence, > multiple implementations is a very positive thing for a software > project...particularly a language. It will be interesting to see how it approaches the issue of Asciidoc being *deliberately* undefined in some places due to being a markup in a natural language environment, a place that is fairly hostile to formal language techniques :) But do agree that multiple implementations are good, so long as they are compatible. If they have their own variations then the overall value to users goes down not up. It helps improve both the quality and > adoption of the language, and vet the ambiguities. See note above :) In the case of AsciiDoc, > it will also make it easier to use with Ruby and the JVM in general (since > JRuby is so fast and very active, whereas Jython is neither). (Who knows, > perhaps we could even get a standard out of it down the road). > Then again you have to care about the JVM for that to matter. > Question: Should we invite the authors of asciidoctor to migrate the > repository to the asciidoc organization on GitHub? I suggest that alternate implementations need to at least be able to process all the distributed examples files, and possibly the testasciidoc regression tests, before they are made part of the organsiation, having incomplete alternative implementations is not a benefit. > > I think moving asciidoctor to http://github.com/asciidoc/asciidoctor would > increase participation and speed up the progress of the effort. I am not sure that you will see much difference if its under the asciidoc organisation, and until it is complete and stable it should not be a distraction for users. That doesn't mean it is bug *free* of course :) > > Success of that project means that AsciiDoc will make it into more places. I > know a few organizations, including the Awestruct and Arquillian projects, > which have a vested interest in seeing this port through. > Great, hope it gets lots of assistance. > I'm also excited about the ability to use *any* view language available for > Ruby to create backends, thanks to integration with Tilt [2]. For as much as > I like AsciiDoc, I'm not very fond of the current approach to creating > backends. The syntax is a bit esoteric when compared to view languages like > Erb, Haml, Slim, etc. Additionally, these view languages give backend > authors a lot more power to control the output that is generated because you > can use the full Ruby language...and you can even use different view > languages for different blocks. And filters are just trivial. > Whoa there, now you are talking about incompatibilities, and as I said above, thats bad. Yes the Asciidoc conf files are baroque (they are *not* Python, but are similar) but given that many projects have their own custom conf files, differing configuration techniques mean that those documents become unusable. Thats unexceptable for any large user, the cost of changing configurations is significant, and makes reusing older documents harder. Remember, a lot of Asciidoc users are targetting things beyond HTML, they are not programmers and Asciidoc is a *content* markup, not a presentation language. This means it can be re-targeted to differing presentation formats essentially unchanged. As for use of programming language features within documents (Ruby, Python etc), *no way*, users who are documentation specialists are *not* programmers, and having code associated with documents is a security nightmare, even the current ability to invoke commands is problematic in that regard. Of course if what you are talking about is a presentation step after Asciidoc then thats fine, Ruby is a tiny improvement on XML :), but it doesn't sound like it in the description above. Cheers Lex > -Dan > > [1] https://github.com/erebor/asciidoctor > [2] https://github.com/rtomayko/tilt > > -- > Dan Allen > Principal Software Engineer, Red Hat | Author of Seam in Action > Registered Linux User #231597 > > http://google.com/profiles/dan.j.allen > http://mojavelinux.com > http://mojavelinux.com/seaminaction > > -- > You received this message because you are subscribed to the Google Groups > "asciidoc" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/asciidoc?hl=en. -- You received this message because you are subscribed to the Google Groups "asciidoc" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/asciidoc?hl=en.
