[editor-hints-devel] My thoughts about markup and docstrings
Tobias C. Rittweiler
tcr at freebits.de
Sat Dec 27 14:04:28 UTC 2008
David Lichteblau <david at lichteblau.com> writes:
> (annotate-documentation (foo function)
> (:argument a "This is the important argument of type BAR")
> (:argument b "This is the BAZ being frobbed in some special way")
> (:return-value "random junk of type QUUUX")
> (:condition big-mistake-error)
> (:see-function the-other-function))
This looks all good. I do have some suggestions:
* In the documentation of ANNOTATE-DOCUMENTATION, do not talk about
"forms", but about "clauses".
* Add a (:RESTART) clause.
* Instead of (:SEE-ALSO-FUNCTION) (:SEE-ALSO-TYPE) &c, make it
(:SEE-ALSO :FUNCTION) and so on. Where the second clause argument is
any symbol, and where this set of symbols can be extended.
* For each symbol given in the clauses perform a consistency check,
i.e. for (:CONDITION FOO) if FOO really names a condition, if not
signal a style-warning.
(It should probably be possible to turn this behaviour off by
setting some special variable to NIL at compilation-time.)
I experimented with a sexp-style documentation format, too. See [*].
> Parse-docstrings' main API function is DOCUMENTATION*, which is like
> DOCUMENTATION, but
> - returns CLOS objects instead of a string
> - uses the annotation macro instead of (just) the docstring
I'd call it STRUCTURED-DOCUMENTATION, ELABORATE-DOCUMENTATION, or
similiar.
[*] -
http://common-lisp.net/websvn/filedetails.php?repname=editor-hints&path=%2Ftrunk%2Feditor-hints%2Fdoc%2Fdefreadtable-clhs-page.lisp&rev=0&sc=0
More information about the editor-hints-devel
mailing list