On Mon, Jun 10, 2013 at 9:55 PM, ghillert [via Asciidoctor :: Discussion] <[hidden email]> wrote:

Thanks for the answers. This blows though - It kind of breaks our tool-chain. I totally did not expect that links are not rendered with the proper extension  (depending on the selected backend)

Actually, this can be solved with the toolchain as is. Go ahead and set the following attribute in the header of the document:

:relative-ext: .asciidoc

And reference in as follows:

* link:other-doc{relative-ext}

That will work on GitHub.

When you run Asciidoctor, whether it's part of your build or invoking asciidoctor directly, just override this attribute using:

asciidoc -a relative-ext .html ...

or

asciidoc -a relative-ext .xml ...

depending on the backend (I'm still thinking how to do it dynamically in this scenario).

Speaking about the feature in general, the issue isn't that AsciiDoc/Asciidoctor doesn't render with the proper extension, it's that it doesn't interfere with the target of links as written.

...however, this is an excellent opportunity for Asciidoctor to move AsciiDoc forward. We need to decide what we want it to do and when that behavior should kick in. The best way to get that going is to create an issue.

https://github.com/asciidoctor/asciidoctor/issues/417

Should we activate the feature when the extension of the link is a known AsciiDoc extension? Or should we require a special attribute on the link macro (inside the square brackets?) If we can sort it out in the next week or so, we'll make it part of 0.1.4.

 

Are there any indication of when GitHub will upgrade?

I have good reason to believe it will be very soon. I'll stay on it until they do.

-Dan

--

Dan Allen | http://google.com/profiles/dan.j.allen