On Sat, 14 Aug 2010, Martin Peach wrote:
Yes, if an external could generate its own help patch that would be something.
Jonathan proposed something similar a while ago. It would not work the same for all externals. GridFlow externals still have their own method-lookup guarded every time by a universal class_addanything... several meta-externals (language interfaces to make externals in other languages) do the same kind of thing.
It can't be fully automatic, because the doc generation tools can't inspect an external to the point of knowing which arguments will allow it to be created, how that affects the number of inlets, and all the nonfirst inlets (or all the inlets when using CLASS_NOINLET) go through t_inlets that you can't necessarily find in the class-table, and if you do find them, you can't associate them with each other until you have seen an instantiated object... etc. the trouble is endless.
The symbol table could be translated on the fly but the comment block is more difficult.
Wait, do you mean the external's code would use special commands to get the doc generated ? We were only thinking of generating the base structure of the help file to be filled in.
What do you mean by "translation of the symbol table" ? from what to what ? (btw, the symbol table has no class pointers)
Writing all of the doc in a non-pd format would help deal with the ordering of the comments and the diffs, but it wouldn't help us integrating any pd-specific features in the doc. (you can't auto-generate very meaningful examples of uses of pd objects...)
I still think that *-help.pd files should be the 'source code of the documentation' : it should be the place where we do all the editing. But I wouldn't prevent someone from having their own different system where *-help.pd files are generated.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801