Support for AsciiDoc #470
Comments
|
I confirm I badly need the asciidoc support for hugo ! |
|
I posted this in the Feature Request section of the forum a few days ago as I wasn't aware of this ticket. I figured I'd go ahead and crosspost it here for completeness. I'd also love to see support for AsciiDoc in Hugo. Markdown is fine for simple posts to Stack Overflow, issue reports on GitHub, Bugzilla reports (a recently added, long overdue, feature), and other lightweight use cases but it doesn't have anywhere near the expressiveness of AsciiDoc. As Dan Allen so eloquently, if not a slightly inflammatorally (I don't care if that's not a word, it should be and English is a living language), put it in his Google+ post:
AsciiDoc is not only far richer but there are already high quality tools for producing a wide range of output formats: HTML5, XHTML, DocBook, PDF, EPUB, DVI, LaTeX, roff, and Postscript, to name a few. You may ask how many of those formats would useful in in the case of a blogging platform but I doubt that I'm alone in really liking the idea of having my posts available for download in PDF and EPUB formats. This would make it possible to easily email a PDF of a post to a colleague or to have the option of loading a long post onto your ebook so you can read it on your daily commute on the train or maybe on a long flight. It would also allow well formatted for posts to later be reused in a project's documentation (the less time I have to spend writing docs the better, reuse is a wonderful thing). I'm not saying that Markdown should be replaced, or for that matter, even depreciated. I can imagine banging out a quick post using Markdown and other times for more complex posts using AsciiDoc. I simply can't fathom any downside to offering users more options. I can understand not wanting to take on the extra work required to write an AsciiDoc interpreter or porting AsciiDoctor from Ruby to Go but as luck were to have it you don't have to. It would seem that, the obviously talented, VonC has done much of the work already with his AsciiDocGo project (he even included unit test coverage for the entire codebase). And to make things even simpler he has made his code available under the MIT license which makes it 100% compatible with Hugo's new Apache 2 license and likely with the <0.13's SimPL 2.0 license. |
|
asciidoc +1 |
|
asciidoc +1 |
2 similar comments
|
asciidoc +1 |
|
asciidoc +1 |
|
Don't worry folks, Steve (aka @spf13) has stated publicly[1] that he's diligently working on a solution to bring asciidoc support to Hugo. [1] http://discuss.gohugo.io/t/contributing-golang-code/223/3 |
|
I've made good progress on this. Love seeing the enthusiasm here. |
|
@spf13 thanks! Liking Hugo thus far, making and using a theme seems easy and intuitive (so far) ;) |
|
+1 for asciidoc |
|
I really hope in v0.13 even if it's just experimental. Steve Francia On Thu, Jan 22, 2015 at 7:18 PM, Brendan Graetz notifications@github.com
|
See #470 * Based on existing support for reStructuredText files * Handles content files with extensions `.asciidoc` and `.ad` * Pipes content through `asciidoctor --safe -`. If `asciidoctor` is not installed, then `asciidoc --safe -`. * To make sure `asciidoctor` or `asciidoc` is found, after adding a piece of AsciiDoc content, run `hugo` with the `-v` flag and look for this message: INFO: 2015/01/23 Rendering with /usr/bin/asciidoctor ... Caveats: * The final "Last updated" timestamp is currently not stripped. * When `hugo` is run with `-v`, you may see a lot of these messages INFO: 2015/01/23 Rendering with /usr/bin/asciidoctor ... if you have lots of `*.ad` or `*.asciidoc` files. * Some versions of `asciidoc` may have trouble with its safe mode. To test if you are affected, try this: $ echo "Hello" | asciidoc --safe - asciidoc: ERROR: unsafe: ifeval invalid asciidoc: FAILED: ifeval invalid safe document If so, I recommend that you install `asciidoctor` instead. Feedback and patches welcome! Ideally, we should be using https://github.com/VonC/asciidocgo, @VonC's wonderful Go implementation of Asciidoctor. However, there is still a bit of work needed for asciidocgo to expose its API so that Hugo can actually use it. Until then, hope this "experimental AsciiDoc support through external helpers" can serve as a stopgap solution for our community. :-)
|
Hi @tbrooke, @ejemba, @voxadam, @txchen, @ollin, @0xMF and @bguiz, An experimental support for AsciiDoc has been added in Pull Request #826. Caveat: Since Asciidoctor is not written in Go, it would be slow, but it works! :-) There may be some quirks and idiosyncrasies, so your feedback is very welcome and very much needed. So, please try to build from source with #826 applied, and start using it in your projects, and give us feedback on what works and what don't! Many thanks! |
|
@anthonyfok Thanks for the great work. My trivial tests so far have been OK, but it looks like @bep has done a rather comprehensive one already: #826 (comment) @VonC I was going to say the same as what @bep said here: VonC/asciidocgo#1 |
See #470 * Based on existing support for reStructuredText files * Handles content files with extensions `.asciidoc` and `.ad` * Pipes content through `asciidoctor --safe -`. If `asciidoctor` is not installed, then `asciidoc --safe -`. * To make sure `asciidoctor` or `asciidoc` is found, after adding a piece of AsciiDoc content, run `hugo` with the `-v` flag and look for this message: INFO: 2015/01/23 Rendering with /usr/bin/asciidoctor ... Caveats: * The final "Last updated" timestamp is currently not stripped. * When `hugo` is run with `-v`, you may see a lot of these messages INFO: 2015/01/23 Rendering with /usr/bin/asciidoctor ... if you have lots of `*.ad`, `*.adoc` or `*.asciidoc` files. * Some versions of `asciidoc` may have trouble with its safe mode. To test if you are affected, try this: $ echo "Hello" | asciidoc --safe - asciidoc: ERROR: unsafe: ifeval invalid asciidoc: FAILED: ifeval invalid safe document If so, I recommend that you install `asciidoctor` instead. Feedback and patches welcome! Ideally, we should be using https://github.com/VonC/asciidocgo, @VonC's wonderful Go implementation of Asciidoctor. However, there is still a bit of work needed for asciidocgo to expose its API so that Hugo can actually use it. Until then, hope this "experimental AsciiDoc support through external helpers" can serve as a stopgap solution for our community. :-) 2015-01-30: Updated for the replaceShortcodeTokens() syntax change 2015-02-21: Add `.adoc` extension as suggested by @Fale
|
Well, it's telling me it's v0.14-DEV (I built master). And, yeah, the commit looked like it should recognize 'adoc'. Maybe I'll try a few other variations. And should the generated front matter markup be asciidoc or markdown? |
|
Thanks for catching that, @sjfloat! A fix has just been committed for ".adoc" file extension recognition. |
|
Will do. Thanks for jumping on that so quickly!
|
|
Yeah, seems to work. I need to familiarize myself with Hugo before I can comment further. |
|
Hi, very interested in using AsciiDoc for a project and curious about Hugo. Any updates on support? Is the dev version near release? Thx! |
|
@anthonyfok Same as with reST support test - using Pandoc's README, although it renders (much) better, but I see in the terminal: How to get more output besides '-v' ? |
|
Nice work! I noticed that you're using a regexp to extract the I also recommend passing several attributes to the AsciiDoc processor so that authors can tailor content for the environment. Here are the attributes we've been setting (as applied to Hugo).
You'd pass these as follows: Of course, if you find other default settings to be useful, you can consider passing those as well. If you append a |
|
Shouldnt this issue be closed consindering that the milestone tag for this issue is v0.14 and it has been released as announced here: https://github.com/spf13/hugo/releases |
|
The current implementation is only temporal (hopeful). |
|
I just tried to add an foo.asciidoc file with a frontmatter and some random chars in the content, but it will not render. The only thing I see is the title (filename) of the post. Is there any way to get more debugging? I do have a2x in my path, if that is what the temporal solution of asciidoc is using. |
|
I just tried to use master, and I can render some asciidoc, but it will not upport the asciidoc include stuff and images seem to be wrong (not rendering), but I have not debugged those. This against 9b3d0cf. |
|
Let's close this issue as we have accomplished our immediate goal, i.e. support for AsciiDoc, albeit experimental and through external Python-based (asciidoc) or Ruby-based (asciidoctor) helpers... And open a new one for the native Go implementation of AsciiDoc support! Please continue our discussions at #1435: "Add support for native Go implementation of AsciiDoc". |
|
Except that using asciidoc does not work, although asciidoctor works. |
See gohugoio#470 * Based on existing support for reStructuredText files * Handles content files with extensions `.asciidoc` and `.ad` * Pipes content through `asciidoctor --safe -`. If `asciidoctor` is not installed, then `asciidoc --safe -`. * To make sure `asciidoctor` or `asciidoc` is found, after adding a piece of AsciiDoc content, run `hugo` with the `-v` flag and look for this message: INFO: 2015/01/23 Rendering with /usr/bin/asciidoctor ... Caveats: * The final "Last updated" timestamp is currently not stripped. * When `hugo` is run with `-v`, you may see a lot of these messages INFO: 2015/01/23 Rendering with /usr/bin/asciidoctor ... if you have lots of `*.ad`, `*.adoc` or `*.asciidoc` files. * Some versions of `asciidoc` may have trouble with its safe mode. To test if you are affected, try this: $ echo "Hello" | asciidoc --safe - asciidoc: ERROR: unsafe: ifeval invalid asciidoc: FAILED: ifeval invalid safe document If so, I recommend that you install `asciidoctor` instead. Feedback and patches welcome! Ideally, we should be using https://github.com/VonC/asciidocgo, @VonC's wonderful Go implementation of Asciidoctor. However, there is still a bit of work needed for asciidocgo to expose its API so that Hugo can actually use it. Until then, hope this "experimental AsciiDoc support through external helpers" can serve as a stopgap solution for our community. :-) 2015-01-30: Updated for the replaceShortcodeTokens() syntax change 2015-02-21: Add `.adoc` extension as suggested by @Fale Conflicts: helpers/content.go
Commit 358dcce supposedly added ".adoc" extension recognition for AsciiDoc, but one place was missed. Thanks to @sjfloat for reporting the bug! See discussions at gohugoio#470.
|
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
No description provided.
The text was updated successfully, but these errors were encountered: