-
-
Notifications
You must be signed in to change notification settings - Fork 7.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for native Go implementation of AsciiDoc #1435
Comments
Note that the linked AsciiDocGo project is unmaintained, and is likely to remain so - see VonC/asciidocgo#1 (comment) - where the author says it only covers about 10-15% of the surface area covered by AsciiDoctor. That being said, I would still very much like to see this happen. This begs the question - is Hugo going to attempt to use AsciiDocGo, or write its own implementation? |
Yes, @bguiz, I agree with you totally. Consider this issue more a "Call for Action" for volunteers to take up this worthy but challenging task. It won't happen right away, but if the demand is high enough, I am sure someone will take up the task and either continue with the great work that @VonC started, or start a new implementation if that is easier. Perhaps some kind of open-source bounty or crowdfunding could be considered too, a possibility as our community continue to grow. Just some random ideas. :-) Meanwhile, I am starting to think that whether some kind of a mythical Ruby-to-Go converter would be feasible to help with this task, haha! I can always dream. 😉 |
I wonder if there might be a way to use https://github.com/robertkrimen/otto to render asciidoc with |
That sounds slow. |
Could be. If the otto is slow then it is sure to be. But it might be a way to make the asciidoc solution self-contained rather than relying on the external process (which is also slow). Anyway, just tossing it out there. I was inspired by the mythical ruby-to-go converter comment above. (asciidoc.js is generated by a ruby-to-js converter from what I understand). |
I bought into the Asciidoc thing and invested in it for my new Hugo site. Only now as the content grows I begin to realize the performance penalty I'm getting from it. The projects to build a faster Asciidoc linked here seem completely stalled, unfortunately... I'm using the Ruby Asciidoctor. Is the Python-based Asciidoc any less horrible in terms of performance? It's a real pity, because apart from the slow compilations, I'm really loving the format... a perfect fit for Hugo if you ask me - modern, well-designed, simple and direct. |
THere's a new library coming up - https://github.com/bytesparadise/libasciidoc It's probably still early days but it's driven off the PEG grammar so much likely to be robust. I'm posting this here in the hope that folks who're interested and invested in asciidoc can probably head out to the libasciidoc project and help out. |
hello @raghur thanks for posting the link to libasciidoc. I've been developing it with the idea in mind that it could be used to render |
@xcoulon have you made any progress with |
@etsauer sorry for the delayed response. I'm still working on libasciidoc, indeed, and there are still a handful of issues that I'd like to address on before making a |
@xcoulon yes, a feature toggle for the first release would be nice. Let me know when there is something worth testing, and i'll gladly provide feedback. |
Nice work @shuLhan! I'm still make progress on libasciidoc and I hope I can start working on the integration with Hugo soon now 🤞 |
Starting with v0.14 (released in May 2015), Hugo provides preliminary support for AsciiDoc with the help of an external helper such as
asciidoc
(Python-base) andasciidoctor
(Ruby-based).Please see Issue #470 "Support for AsciiDoc" (which led to the current experimental "external helper" implementation) for more information. This issue
However, the ultimate goal is for Hugo to support a native Go implementation of AsciiDoc, something that e.g. the https://github.com/VonC/asciidocgo project set out to accomplish. This issue will track the progress on that front.
The text was updated successfully, but these errors were encountered: