Fri Mar 11 18:10:17 CET 2016
Have a look at https://github.com/erldocs/erldocs/blob/master/src/erldocs_core.erl
It already goes through the trouble of reading docs from src or doc/src and applies some transformation before rendering HTML from XML.
I have a Markdown-from-XML renderer in the works too.
> On 11 Mar 2016, at 08:48, Federico Carrone <federico.carrone@REDACTED> wrote:
> I already started working on this after getting a few useful comments from Kenneth.
> I hope to have a simple HTML demo to get feedback from the community in one month or two. After getting feedback I will work on the pull request.
> If you have any comments/ideas please send me an email.
> FYI I am using the recommendations of:
> And as Inspiration I am using:
> Rust docs
> Python documents redesigned
> Racket docs
> Elixir docs
>> On Wed, Mar 2, 2016 at 9:58 AM zxq9 <zxq9@REDACTED> wrote:
>> On Wednesday 02 March 2016 12:38:52 Ali Sabil wrote:
>> > Thank you for bringing this up. An improvement to the presentation of the
>> > Erlang documentation is very much needed.
>> > I have started looking at this myself sometime ago, here is what I gathered:
>> > • The OTP documentation is using erl_docgen which is mostly XSLT based
>> > • Edoc is not that much used in OTP, the applications that do rely on
>> > it, use a custom layout (otpsgml_layout) to generate output that can be
>> > consumed by erl_docgen.
>> > • Experimented with adding a modern HTML5 output to erl_docgen here:
>> > https://github.com/asabil/otp/tree/feature/html5-docs but this proved
>> > itself challenging.
>> > • Started working on a modern doclet for edoc, based on the ex_doc
>> > layout: https://bitbucket.org/asabil/edoc-modern
>> Hi Ali,
>> I ran into the exact same thing and concluded it would be easier to treat
>> rendered docs as their own data source rather than try to decobble all the
>> mix-and-match that exists within the OTP sources themselves (though the
>> *right* approach would be to actually make the docs across OTP uniform --
>> I felt this would be futile to even attempt alone and unsupported, who has
>> that much (un)paid time on their hands?).
>> Tricky, to say the least.
>> erlang-questions mailing list
> erlang-questions mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions