|
Hi,
As Steve mentions, there is a documentation language[1] as part of Koneki LDT [2] that, in addition to enable LuaDoc style documentation in the IDE, is also used to provide code assistance. The documentation can be written in Lua source files, but there is also a way to reference pre-packaged documentation in the IDE. We call these packages "Execution Environments"[3]. You may want to play with the IDE and see if the documentation language matches your needs (we provide the EE of Lua 5.1 and Gideros Mobile[4], and there is also the documentation for Love2D [5]). The language parser is in pure Lua and open source, available in Koneki LDT's repo. We are definitely looking forward to getting feedback on this and collaborate with others to improve tooling for Lua. Kevin [1] http://wiki.eclipse.org/Koneki/LDT/Technical_Documentation/Documentation_Language [2] http://eclipse.org/koneki/ldt [3] http://wiki.eclipse.org/Koneki/LDT/User_Guide#Execution_Environment [4] http://sierrawireless.github.com/lua-execution-environments/ [5] https://github.com/mkosler/LOVELuaDoc [6] http://www.eclipse.org/forums/index.php?t=thread&frm_id=221 Le 07/09/2012 21:25, steve donovan a écrit : On Fri, Sep 7, 2012 at 3:20 PM, Javier Guerra Giraldez <javier@guerrag.com> wrote:my vote is for using LuaDoc hints. metalua is impressive, but i think most of my code wouldn't be analyzable without actually running it.The Koneki Eclipse LDT [1] actually uses both strategies. LDoc implemented extended tags-with-attributes like '@tparam string name first name of person', where '@tparam string' could be further aliased to '@string'. Basically so that doc strings could capture more semantic information - if we have a function marked with '@tret MyObject' then the static analysis can work from there. And then there's LuaInspect [2], which is a plugin for SciTE and vim. This does metalua-style static _plus_ dynamic analysis. It isn't an easy or clean problem.... B 1. http://www.eclipse.org/koneki/ldt/ 2. http://lua-users.org/wiki/LuaInspect |