Code Assist prototype feedback [message #1416417] |
Thu, 10 May 2012 17:33  |
Eclipse User |
|
|
|
Some feedback after having tried out the Koneki code assist prototype as available from wiki.eclipse.org/Koneki/LDT/Technical_Discussions/User_Assistance
(pff not allowed to post links..)
Issues:
- The lua code outline in your own project files no longer list your own (undocumented?) functions. This isn't really handy during development, or if you just use code-assist for the standard library completion.
- By trial and error I found that only files somehow referenced in the global.lua in the 'root' of the build path are parsed. It would have better to scan all '.lua' files for module / func definitions?
- It does not seem possible to create fields in the global module that start with a capital letter. (auto-complete once successfully, seconds time fails)
A good effort, but was hard to really test, without the normal auto-complete also working. :)
|
|
|
|
|
Re: Code Assist prototype feedback [message #1416425 is a reply to message #1416419] |
Mon, 14 May 2012 13:44   |
Eclipse User |
|
|
|
Hi,
a few answers to your remarks:
Quote:
> The lua code outline in your own project files no longer list your own (undocumented?) functions. This isn't really handy during development, or if you just use code-assist for the standard library completion.
We know that and we agree, it's a limitation (even a regression compared to the previous version). In this version you only see first level local variables and elements extracted from documentation (module, function, field ..).
This limitation is because we decided in a first time to extract API information only from documentation, to be able to support any way to implement a module.
You could see some http://wiki.eclipse.org/Koneki/LDT/Technical_Discussions/User_Assistance or https://bugs.eclipse.org/bugs/show_bug.cgi?id=370583 about this choice.
We hope all the advantages (better HTML documentation, usable content-assist, semantic-highlight ...) will counteract this outline problem.
In the future, we would like to add some code analysis to propose outline and content assist even for undocumented code.
Quote:
> By trial and error I found that only files somehow referenced in the global.lua in the 'root' of the build path are parsed. It would have better to scan all '.lua' files for module / func definitions?
All the files in the buildpath are parsed.
We support local variable completion for all files.
We support module completion for all files (if it has been loaded with the lua 5.2 recommended way : local m = require 'mymodule')
For global variable, it's a bit more complicated, because it's hard to know if a global var is available and so if we could propose content-assist. Furthermore, the use of global var is not really recommended, so supporting it is not a priority for us.
There is an exception, the global var already loaded by the Lua VM at startup. Those must be always available in content-assist. So the purpose of the file global.lua is to describe those globals.(In our next version we will provide the notion of Execution Environment and all of this will make more sense)
|
|
|
|
Powered by
FUDForum. Page generated in 0.05575 seconds