Bug in code complete?

Glider (IDE)
#1

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…

G

#2

Hello G,

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:

http://view.xscreenshot.com/3978ad5a3fc9b86ed0a5bd1c0acdd41f

Regards,

M.Y. Developers

#3

Issue fixed, update available shortly.

#4

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.

#5

Hello gslender,

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.

Regards,

M.Y. Developers

#6

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.

G

#7

The new analyzer actually does pull that stuff out of the methods. We will add this feature to the next update.

Regards,

M.Y. Developers

#8

Sweet! Looking forward to the next update then!

#9

@G,

There is an update that fixes the autocomplete issues. There are a few things you should be aware of:

When you invoke autocomplete on a table based function you will get additional entries like this:

http://view.xscreenshot.com/86837e349264865d0ebf99a1b5f7b8a3

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…

if you invoke autocomplete inside a table 

http://view.xscreenshot.com/1ebdc5ca160a5c822624e37cee049d0d

You will get a list of table keys. 

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:

--- -- @param options @class table -- @return @class ButtonWidget -- function widget.newButton( options ) options.id = "" options.left = 1 options.right = 1 options.label = "" options.labelAlign = "" options.labelColor = {} options.labelXOffset = 1 options.labelYOffset = 1 end

There is nothing special about the stubs, the IDE treats them the same as your lua code. 

Regards,

M.Y. Developers

#10

How do you do that? and where is the docs for all this?

G

#11

where is the docs for all this?

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. 

Regards,

M.Y. Developers

#12

Yep updated fine.

I’m seeing this though and nothing like what you’ve shown above…

uepte.jpg

G

EDIT > I fixed the “new” operator mistake (hang over from Java coding) and still made zero difference. On Mac OS X btw.

#13

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.

Regards,

M.Y. Developers

#14

Here is a quick code snippet to demonstrate the feature:

function tabFunc(tab) tab.param1 = 2 tab.param2 = "" tab.param3 = true tab.param4 = {} end tabFunc--invoke code compete here

Regards,

M.Y. Developers

#15

…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 ??

G

#16

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?

G

#17

why not on the Corona supplied Lua code ??

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:

  1. Type information, is it a number? string? bool?
  2. Parameter information. How many? What type are they? Are they optional?
  3. Descriptions
  4. 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.

Regards,

M.Y. Developers

#18

Hello G,

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:

http://view.xscreenshot.com/3978ad5a3fc9b86ed0a5bd1c0acdd41f

Regards,

M.Y. Developers

#19

Issue fixed, update available shortly.

#20

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.