OpenFL completion not working on some cases.

[aaulia]

Hi, this has been happening for a while now, but I'm too busy to report it, but it's getting annoying as of late. The symptoms that I gather is that whenever I access OpenFL's classes such as openfl.Assets or openfl.Lib the completion on the whole file suddenly broken because or error about missng lime classes.

The other error that I get is about nme not installed.

[haxiomic]

For the moment, it seems like adding <haxelib name="lime" /> to the project xml does the trick - although be sure to add it before <haxelib name="openfl" /> so openfl still controls the build

[clemos]

I don't use OpenFL / lime much personnally, and don't have currently much time to fix this. Maybe @underscorediscovery can help ?

[ruby0x1]

This is related to the way the projects are used by the plugin, and what the original refactoring I was doing was trying to get at - They should be requesting the information from the build tools (lime display) because the project format has dependency trees that the plugin is not looking at.

Because the plugin sees "openfl" only as a <haxelib/> node, it misses the fact that inside openfl include.xml it includes lime, and possibly others. This means any direct dependency will be found by the class path and any indirect dependencies cause trouble.

Unfortunately at this time I am quite busy - but aside from having no time for this specifically right now, personally the current code (as we discussed before) is just way too unwieldy to hack features into as it stands.

If someone was looking to solve this with the existing code, the code that parses the xml nodes for the haxelib items, this will fail as well. There are conditional nodes that are set by the build tools in the dependency tree that only apply based on target, based on defines, and more. You would be replicating a large % of the actual build tools purpose by doing this, and it will still give flakey results.

This is better done the correct way - by querying the build tools to tell you the final dependency list from the hxml, or running the lime update command and simply grabbing onto the .hxml file that it puts in the folder, but the only correct way to get reliable completions is to ensure all dependencies up the tree are accounted for by the include xml files, and the only way to get that properly is from the display command or less reliably (since the file can be deleted etc) the build generated hxml.

Hope that helps!

[vnedilko]

Hi, any updates about fixing this?

[clemos]

I personnally don't use lime / OpenFL / NME much, so I don't have much time to handle this. I agree it would be much better to use the appropriate framework commands to get the haxe compiler options needed for completion and stuff. I also agree the bundle code is not very well structured / not easy to play with. But I'm not sure it would be such a pain to implement. I guess I could give it a try at some point, but I'd need someone to test it properly, as I usually only test on "basic" sample projects provided by the framework authors. If someone is willing to spend some time trying it properly, please let me know and we'll figure a roadmap.

[clemos]

In the meantime, if lime is able to output an .hxml file, you should be able to use it for completion instead of the xml. I know it's not ideal, as you'll have to switch between builds quite often to autocomplete / build, but it may be a workable workaround for now.

[xavierstampslafont]

I was having a similar issue (#187), but it was complaining about lime.Assets. clemos directed me to this issue, and indeed, adding the <haxelib name="lime" /> dependency fixed the autocompletion for now.

The real fix will be much appreciated when it comes out :)

[tastytentacles]

note about the quick fix, inserting haxelib name="lime" in the project.xml is breaking my build. the auto correct works but I have to remove it before I can successfully compile anything.

[ghost]

added temporary fix autocompletion should work without adding <haxelib name="lime" /> compilation should work as well

[ghost]

Please test.