This is the mail archive of the guile@cygnus.com mailing list for the guile project.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
>>>>> "Jim" == Jim Blandy <jimb@red-bean.com> writes:
Jim> If the goal is to provide on-line documentation associated
Jim> with SCWM procedures, I would be much happier with a system
Jim> that extracted in the reverse direction: from a manual to a
Jim> database accessible by the code.
Jim> For example, go ahead and write texinfo or DocBook describing
Jim> the SCWM functions, then have a program grunge through the
Jim> @deffn's (or the DocBook equivalent) and build a database,
Jim> then have SCWM retrieve that text upon user request.
Jim> Or, if you think it is valuable to have the text mingled with
Jim> the source code, add a notation to your manual format that
Jim> says "extract the docstring for this function from the
Jim> source, and insert it here." That way, the layout of the
Jim> source has no influence on the layout of the manual.
This is like the dream I had... Where `info' does that in GTK XEmacs
2000 beta 666, making it possible to write a good manual without having
to paste in those darn docstring snippets. Let the viewing tool do
it for you.
Jim> Do people feel that, if the documentation is a separate file,
Jim> programmers will be discouraged from writing docs, whereas,
Jim> if the documentation were mingled with the source, then
Jim> programmers would naturally write docstrings as they go
Jim> along?
No... but the function/variable documentation belongs in the code
next to what it's talking about. It occurs to me that you could have
specially marked up comments that are extracted also, so they'll be
inserted at the point of the @inserthere{comment:thisfile.c:identXX}.
Hmm. XML, SGML, or Texinfo? I'm just a new gnu...