lua-users home
lua-l archive

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


As, an example. Here is the description of the Lua standard library.

https://bitbucket.org/sylvanaar2/lua-for-idea/src/687562db94127a36b0e95b49a6bdfda2af6d94da/resources/stdlibrary?at=idea13


On Mon, Aug 12, 2013 at 8:18 PM, Jon Akhtar <akhtar@mindspring.com> wrote:
I have been for some time wrestling with  how to get my Lua IDE [1] to support easy user supplied API definitions when the users may only have documentation to go on.

My initial thought was that since my editor supported type inference of Lua source code. I could reuse that work to allow API's to be defined using Lua. This works. I use it to define the file object in the io library.

given

local a = io.open

typing a(): will provide completions for functions on the object returned by io.open().

The problem with this of course is it is quite complicated by nature, and to top it off my system used the module function as a sort of pseudo keyword in order to reduce the overally complexity of code analysis. For example getting all the Penlight code to understand its own self references took some work - but it did work last time I tried browsing the source.

Couple this with my other great idea to let you provide code documentation using Lua scripts has lead to a system with a steep learning curve, and somewhat unpredictable behavior.

Basically there is a lua script you can supply that will ask you for the parameter info, short-text docs, long text docs, and link to and external source. This has honestly worked really well for me, other people have had trouble understanding it - but it is probably  one of the easiest to methods I have seen for solving this part of the problem.

I was wondering what ideas the community may have or know about that would be useful in this regard. All angles of describing an API - but specifically, the OO constructs, that use metatables or plain functions on Class objects to let you create instances of a given class.

These have complex return types, and those return types will also need to be understood by the documentation component. So a list of methods you can call -i isn't enough. You also need to be able to identify these object usages and provide documentation on types they may return, etc.

In my current system - you can provide semantically aware completions using  Lua source code.
My goal was to reuse the code inference that was providing completions everywhere else - and not require a special type description DSL.

I have changed jobs this year which has meant not working on the plugin, but I'd like to restart. I have discovered I either need help on the project, or need to engage the community more as I design things to ensure that I don't overlook any really great ideas.

Anyhow - thank you in advance for your replies.