AltME: Red Docs

Messages

Gregg
Having the doc string there has the benefit of letting you use Find on a web page to help locate what you want by purpose rather than name. Having an a.k.a. (Also Known As) annotation could help too. I did this for myself when starting with REBOL, noting what equivalent funcs were in the environment I was coming from.
Gregg
While I can't commit to being the doc lead, if someone creates templates for output formats, and we have data in REBOL format to populate them with, I will commit, happily, to building doc generation tools.
Just looked at http://clojuredocs.org/clojure_core, and it is *not* a useful layout IMO.
DocKimbel
Gregg: documenting the API (the Red words) is the easy part. The content could (should?) be extracted from the docstrings in boot.red (I haven't add any so far, contributions are welcome).
The level of info displayed by the clojuredocs quickref is fine to me, I have used similar approach in the past for documenting the RSP API:
http://cheyenne-server.org/docs/rsp-api.html
Arnold
Oldes, really nice popups with copy paste. Much better. Hard to believe you need a cheatsheet off-course ;-)
Arnold
So the Red docs are not makedoc(2) specific. You only want to be sure that they are in a format that can be handled using scripts like makedoc123 and generate all kinds of documenttypes, like webpages, pdf, (epub?) etc. If I understand correct.
DocKimbel
Makedoc would be the source format for the docs, the users would consume it in one of the exported formats available.
Gregg
Looking more at sencha/ext-js and closuredocs, I like aspects of both. Sencha has some very nice detail pages, and closuredocs has a clean feel, with easy ways to add examples, see also entries, and comments.
Gregg
Now I have to re-learn fetching the upstream master to my fork...
Andreas
Gregg: unless you actually want to push changes to your fork on Github, there's usually no need to maintain a "fork" on Github.
If you meant how to get the latest changes from Nenad's master into your local repository, that could/should be as easy as `git pull`.
(Depending on where you originally "cloned" from.)
Gregg
I'm trying the github Windows client, which should sync, but only have my fork in it right now. I thought the target workflow (in general) was to fork, push to that, then submit a pull request. My problem is spending little time on it, then letting it sit idle while it leaks out of my brain.
Andreas
Yeah, fork + push to fork + pull request is one typical contribution workflow.
However, if you just want to follow along with the updates, then you don't need your own fork and can just sync a local clone of Nenad's repository.

Gregg
But I should fork+push+pull-req if I want to, say, add comments to %boot.red.
Andreas
Yep.
Pekr
I don't want red docs, I want black&white ones :-)
Pekr
My take is as follows:
- I like REBOL Word Browser - it contains even examples, is then easy to produce runnable examples (Easy VID), allows comments
- REBOL reference manual is good enough. I can't see any advantages with Clojure etc. - imo no need to copy anyone - just make a structures, which allow you to register related functionalities, add comments, examples
- I agree with Doc, that first Doc which should appear is some guide, which leads you via introduction to language, its main ideas and concepts, etc.
- word reference shoudl be auto generated imo .....
Gregg
I thought of the Word Browser as well Petr, and agree with your comments. On ClojureDocs, though, my thought is that the main structure is the auto-generated part, and the comments and examples are added to that.
Pekr
That might work. I wonder about some functionality removal - what happens with related docs then? Is there going to be any versioning? Some good notes might be lost that way ...

Last message posted 404 weeks ago.