guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Scheme file docstring format


From: thi
Subject: Re: Scheme file docstring format
Date: Sun, 18 Feb 2001 01:16:24 -0800

   From: Neil Jerram <address@hidden>
   Date: 17 Feb 2001 09:53:37 +0000

   I don't agree.  If an author documents a non-exported definition,
   then there's probably a good reason why.

   Also, when the REPL is operating outside the module in question,
   normal name visibility stuff will (or can be fixed to :-) hide the
   docstrings of non-exported definitions.  If you then step into the
   module, non-exported names and their docstrings should then be
   visible.

this is reasonable.  then, the requirement becomes: docstring snarfing
should preserve export status of the definition (so that presentation
filters can do their job).

since there is already planned facility for meta info, we can define
some required properties, such as "Export" w/ value either `#t' or `#f'.
(required here means snarfing infers and saves such properties, not that
the docstring writer needs to explicitly note them.)

if docstrings are stored/accessed using the same mechanisms to resolve
module references, maybe the `define-module' form and the value of
applying `module-public-interface' should be considered food for the
snarfer as well.  (an interface-oriented snarfer would be immediately
useful for GUMM [he says selfishly].... :-)

most useful would be some flexibility in what constitutes snarfable
input.  certainly we can mandate files distributed w/ guile to have a
certain format, but it would be nice to be able to snarf other formats
which may be regular in their own way albeit not strictly conforming.
the nice hack would be to heuristically determine which snarfing method
to use given a large-enough set of never-before-seen modules...  anyway,
for an indexing framework implementation, check out imenu.el in your
local emacs installation.

ok, that's all i have to spew on about snarfing...

thi



reply via email to

[Prev in Thread] Current Thread [Next in Thread]