Just starting to use Glider for the first time, but have tried countless other IDEs … so in my “trial” time to see if I can live with Glider…
Ok, so I’m trying code complete…
local tabBar = widget.newTabBar{
buttons = tabButtons
}
tabBar. --> then I press CMD /
and a mega list of methods and properties appears… nice!
I then press the ‘x’ key and only this list appears…
xOrigin
xReference
xScale
what happened to just ‘x’ ???
Most other code complete tools will show you correct/full matches to outline that just x is a valid property… but in Glider I’m not shown this and would/could mistakenly think that .x isn’t a valid property
Interestingly if I use a capital X then the list includes lower case x… so it looks like a bug in the match and remaining list…
That is actually a feature. The reasoning is if you already have it typed out it is probably not necessary to show it in the code completion. But you make a valid point and we will add an option for this behavior.
.x is registered in the autocomplete database, as you can see by the screenshot:
Not sure I agree that’s a feature. If I was to type .k I’d get the same response, which I’d wrongly assume this is a valid code completion confirmation that k is a property, much like x is… Which is why no other IDE does it that way also, but glad you’ve fixed it.
Thanks for the feedback. Is there anything else you want to see improved about autocomplete?Also be sure to try out the documentation viewer. You can open it via window->Documentation window. This will pull up the corona docs for any lua variable/function that currently has focus, this includes autocomplete and caret movements.
I guess adding better parameter options… ie expand newButton (options) into newButton (left ,top, width, height, defaultFile, overFile ,id ,label ,onEvent) etc… I’m guessing pulling this detail out of each method isn’t going to be easy, but would sure help if it preloaded the options with the correct table datanames.
It is based on our lua analysis engine so it should infer the keys properly based on your function. However, this currently only works for functions that have just one parameter, multiple parameters wont be expanded, But…
One more caveat. The corona autocomplete stubs we have right now are not up to date so you might not get this behavior for all functions. For instance, widget.newButton(table) should have all the args expanded out but will not because the stubs do not yet have this detail.
If you ctrl-click on it it will take you to the stub and it looks like this:
--- -- @param options @class table -- @return @class ButtonWidget -- function widget.newButton( options ) end
to support the table parameters, it ends up looking something like:
Have you updated to v 1.9.08 (Help->check for updates)? There is no doc yet for this as it is a new feature. You need to just invoke autocomplete between the two curly braces in a function call.
For instance, widget.newButton(table) should have all the args expanded out but will not because the stubs do not yet have this detail.
The functionality is there but we need to update the content to match up. The corona docs have changed significantly and it might take us a while to update all the stubs to support this feature. This is why it may not work on all the api functions but it should work on your own functions that have table parameters.
…aaahhhhhh, so the IDE still need to be updated with some database that you release based on Corona Docs content which isn’t updated/parsed in realtime. If it works on your own functions in code, why not on the Corona supplied Lua code ??
ok, I think I’m showing my lack of knowledge about Corona development now… so the IDE is reading the Corona supplied Lua code, just that it is stubs with no table defs and so I’m blind… the updated stubs you provide outline this Lua table more so it can be used correctly for parameter stuff… am I close?
There is no supplied Lua code. I bet most of the Corona specific api calls happen in C. Even if we had the Lua source for the library calls we would create stubs out of them anyway as it is much faster to parse stubs than it is to parse implementation code.
so the IDE is reading the Corona supplied Lua code
We created the stubs ourselves based on the Corona API docs. Basically the stubs tell the IDE a few things:
Type information, is it a number? string? bool?
Parameter information. How many? What type are they? Are they optional?
Descriptions
Return statements. How many? what is the type?
The stubs just give the IDE an idea about the environment your scripts run in. In this case its Corona but you can write stubs for your own execution environments. It uses the same lua analysis engine that analyzes your code.
If you are from a java background you can think of these stubs like java interfaces, they are a high level description of the implementation but do not actually do any of the work.
That is actually a feature. The reasoning is if you already have it typed out it is probably not necessary to show it in the code completion. But you make a valid point and we will add an option for this behavior.
.x is registered in the autocomplete database, as you can see by the screenshot:
Not sure I agree that’s a feature. If I was to type .k I’d get the same response, which I’d wrongly assume this is a valid code completion confirmation that k is a property, much like x is… Which is why no other IDE does it that way also, but glad you’ve fixed it.
