In our previous episode, Michael Van Canneyt said: > > fpdoc is great, I simply want to make it even better. > > I am absolutely not against introducing this, I even welcome any attempt to > make fpdoc better.
I think losing full layouting capabilities (even though sometimes problematic) would be an huge loss. Specially because now we are also think about using fpdoc for normal helpfiles. However, Graeme does have a point that it is overkill for many cases, and a simpler option would be ok. > b) It must exist alongside the current format (obviously), and the two must > be mixable on a per-file basis. (that is, one format per file, but 2 > files may have a different format) Ok, you made that point already. > c) all current 'extra' constructs must somehow be supported. > (printshort, img, link etc.) And alink. (which I still have to define :-) It is a link to an abstract tag. It's my next chm package todo point (currently finishing multiple window support). Somewhere else, the abstract tag then generates a list of links that point to that abstract tag. These links are indexed, so that these indexes can be summed up over multiple helpfiles (e.g. make a lemma "stringroutines" that reaches over all stringroutines). IIRC Graeme said IPF also supported this, and for html we can just generate add the linkdata to .xct, and generate static pages from that. Less flexible (only links to lower pkgs work), but already a start. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel