I changed my script that grabs the functions so that it will work with docstrings, but I thought it made more sense to be documenting the main branch rather than the git repo. What do you think?
The Git repo is pretty much a superset of arc0, except for a few bugfixes here and there. Plus if we're going to actually add docstrings to the code, the only way to do that would be to commit them to the repo.
I think it would make the most sense to just document the Git repo and make a note in the documentation that it's not identical to arc0.
OK, I've made a few changes, let me know what you think.
*I put everything into one tree, with a node for each file
*I alphabetized everything, except arc.arc is the first file listed.
*I added the xdefs from ac.scm
*I added a button to expand all the tree (except the source code) so that it's easier to search
I'm not sure yet. I wrote a script that generates all the code from the .arc files, so it would be tricky to throw the docs in there. What may be best would be to use the docstrings that someone has added once they become part of the main release, and I'll change my script to grab those?
I was going to alphabetize, but then I thought that it might be good to see them in the order they are defined in the file. I'll have to make an option to sort them.
* Function or Macro (Split them up and alphabetize them)
* Alphabetical (all in one giant alphabetical list.)
* By file (arc.arc, app.arc, etc.)
You're already doing a combination of two of these, but you should give them as separate options; or perhaps keep what you have and just add all these options. Shouldn't be that hard if you keep all the definitions in a database, with the information required to do this.
