That's good to know. Thanks!
On Mon, Jul 14, 2014 at 4:34 PM, Elias Mårtenson <loke...@gmail.com> wrote: > This information is already stored. The Emacs mode uses this when > navigating to definition of a function. > > Regards, > Elias > On 15 Jul 2014 02:19, "David Lamkins" <da...@lamkins.net> wrote: > >> I apologize for the confusion, but this proposal is about capturing the >> file location of a function's definition; not about the function's >> comments. My lead sentence was just an indicator that the earlier >> discussion of comments triggered this new line of thought... >> >> >> On Mon, Jul 14, 2014 at 11:14 AM, Juergen Sauermann < >> juergen.sauerm...@t-online.de> wrote: >> >>> Hi, >>> >>> my favourite for code documentation is *Doxygen*. It does not currently >>> support APL comments but we might be able to change that. Or use one >>> of the existing tags like --- for *VHDL* or %%% for *Erlang*. >>> >>> It would need some changes in GNU APL - multi-line comments and >>> proper storage of documentation information in the function so that it >>> can de *)DUMP*ed without loosing that information. >>> >>> /// Jürgen >>> >>> >>> >>> On 07/14/2014 07:56 PM, David Lamkins wrote: >>> >>> Elias' thread about docstrings got me to thinking about other function >>> metadata. >>> >>> One thing that might be nice to have is for APL to record the source >>> location of a function's definition. >>> >>> If the function is defined in a file, record the path and the line >>> number of the first line of the definition. If the function is defined from >>> some other source, either record a suitable token that won't be confused >>> for a filename or simply record nothing. >>> >>> The source location information could be exposed to APL programs via >>> an extension to ⎕AT or via a new system function created for this purpose. >>> >>> Source location information could be used to implement a meta-dot >>> command. Unlike an approach that requires use of a tags file (I'd be >>> surprised if ctags or etags even works for APL code), the location >>> information maintained by the APL session would be up-to-date and would >>> correctly distinguish between a function loaded from a file and a function >>> redefined from within the session. >>> >>> Finally, it'd be nice to expose a system function to allow update of >>> the source location metadata for use by tools which need to programatically >>> load APL code from a file. >>> >>> Note that capturing the source file location of a function definition >>> is something that can't already be done in APL without writing APL >>> equivalents of )LOAD, )COPY, )PCOPY, )IN, )PIN, etc. >>> >>> -- >>> "The secret to creativity is knowing how to hide your sources." >>> Albert Einstein >>> >>> >>> http://soundcloud.com/davidlamkins >>> http://reverbnation.com/lamkins >>> http://reverbnation.com/lcw >>> http://lamkins-guitar.com/ >>> http://lamkins.net/ >>> http://successful-lisp.com/ >>> >>> >>> >> >> >> -- >> "The secret to creativity is knowing how to hide your sources." >> Albert Einstein >> >> >> http://soundcloud.com/davidlamkins >> http://reverbnation.com/lamkins >> http://reverbnation.com/lcw >> http://lamkins-guitar.com/ >> http://lamkins.net/ >> http://successful-lisp.com/ >> > -- "The secret to creativity is knowing how to hide your sources." Albert Einstein http://soundcloud.com/davidlamkins http://reverbnation.com/lamkins http://reverbnation.com/lcw http://lamkins-guitar.com/ http://lamkins.net/ http://successful-lisp.com/
