Support for AsciiDoc

[debloper]

Please allow using *.adoc files instead of *.md files as per project preference (with a config options, defaulting to .md parsing, perhaps?).

I want to use docsify for my project, but we have AsciiDoc files for documentation and it's a lossy conversion to convert them to MarkDown.

[trusktr]

This would involve adding a whole new parser/renderer. We are working to clean up the code base, and eventually once things are organized and decoupled enough so that non-markdown features aren't mixed with markdown features, then we can add new renderers.

It shouldn't be too hard to do: send the input out, receive the HTML back, then proceed like before.

[trusktr]

I put this in the 4.x project board because I think this can technically be created without being a breaking change, behind an option.

[anikethsaha]

I am -1 for this as we got some similar requests for other extensions as well.

We cant cover all request. I would prefer some custom tool to convert the other extension to .md and then send them to documentation folder where docsify is being used.

[debloper]

We cant cover all request. I would prefer some custom tool to convert the other extension to .md and then send them to documentation folder where docsify is being used.

AsciiDoc to Markdown is a lossy conversion (as md is less feature rich). I've mentioned this in my initial request. If anyone would be willing to do that, they wouldn't be using AsciiDoc in the first place (and use MarkDown instead).

It sometimes may be infeasible to cater to all requests, but it helps to have a well set out reason/boundary condition for that. For e.g. "if we have more than X number of people expressing interest in a certain feature, we would do it". Not to say popularity is/has-to-be the only metric here, but it's at least objective in some sense (and any other equal/better objective metric would serve this purpose as well).

Having a metric like that would protect you from taking radical all-or-none decisions like this - as you can turn down or pick up features more confidently - without resorting to (or being blamed for) decisional subjectivity.

P.S: I am not as enthusiastic about this particular request any longer as:

1. I've moved on from the project I've mentioned.
2. We ended up using alternative tooling for it anyway.

Nonetheless, I use docsify in some of my personal projects, and would love to see it grow.

[rrjanbiah]

+1 for this feature.

Reason:

We don't have Swagger or ReDoc like tool for CLI tools. As replied me in StackOverflow https://stackoverflow.com/questions/67119924/swagger-like-tool-for-making-documentation-for-cronjobs-workers-cli-commands/70405174#70405174, docsify.js is the closest in this space. Since, asciidoctor supports AsciiDoc to roff manpage format conversion already, it would be a better choice.

[trusktr]

Want to make a pull request for this? It should be behind an option, so backwards compatible.

[johnholliday]

There are several advantages to supporting AsciiDoc as an option. It has built-in support for includes, it is rendered by GitHub and VSCode. This would be a significant enhancement for Docsify, and would likely increase the user base immediately.

[paulhibbitts]

Basic AsciiDoc support is now available via a plugin (https://github.com/gchiesa/docsify-asciidoc) so closing this issue.

BTW, I am using this plugin in my own https://Docsify-This project to display AsciiDoc files and it works quite well, for example https://docsify-this.net/?basePath=https://raw.githubusercontent.com/asciidoctor/asciidoctor-pdf/main/examples&homepage=basic-example.adoc&edit-link=https://github.com/asciidoctor/asciidoctor-pdf/blob/main/examples/basic-example.adoc