From ... Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news.tele.dk!134.222.94.5!npeer.kpnqwest.net!nreader1.kpnqwest.net.POSTED!not-for-mail Newsgroups: comp.lang.lisp Subject: Re: So, where's the "Javadoc" for COMMON Lisp? References: <3B544F2D.2D2B5B99@rchland.vnet.ibm.com> <9j20j2$ifl$2@newsg1.svr.pol.co.uk> Mail-Copies-To: never From: Erik Naggum Message-ID: <3204451328338331@naggum.net> Organization: Naggum Software, Oslo, Norway Lines: 20 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 18 Jul 2001 13:22:10 GMT X-Complaints-To: newsmaster@Norway.EU.net X-Trace: nreader1.kpnqwest.net 995462530 193.71.66.1 (Wed, 18 Jul 2001 15:22:10 MET DST) NNTP-Posting-Date: Wed, 18 Jul 2001 15:22:10 MET DST Xref: archiver1.google.com comp.lang.lisp:13301 * Marcin Tustin > Actually, how powerful is the document string feature? (I'll go read about > it later)? Has anyone found the need to build something more like javadoc > (or Doxygen)? (I do mean javadoc, not api documentation). In this day and age with "web browsers" used for everything, I think it would have been a better idea than my hyperspec.el thing (which others have also done) to keep URLs in the documentation strings of standard symbols and of symbols exported from implementation-specific packages. The generic function documentation does not necessarily need to return a constant URL, but could build it from on-site or off-site base URLs, possibly even build it from the symbol name and documentation type. The Lisp system would interact with the browser with the established remote control features, at least available in Netscape under Unix and Linux. #:Erik -- There is nothing in this message that under normal circumstances should cause Barry Margolin to announce his moral superiority over others, but one never knows how he needs to behave to maintain his belief in it.