Autocomplete pervasive error [detail in issue] about snowkit-fd HOT 11 OPEN

This is a duplicate of luxeengine/alpha#295 :)

We are trying to find out why, I have asked @elsassph for assistance as it's regular haxe features and it's only FD that is affected.

from snowkit-fd.

Damn I forgot to check that.

from snowkit-fd.

No worries @elsassph, you can always grab me on the slack chat if you need me to test anything or need assistance with debugging. Happy to help.

from snowkit-fd.

@underscorediscovery so here's the command FD is using for completion, it's based on luxe info response (luxe draw sample, with just the display info added at the beginning). I do have the same error as reported:

--display "C:\Dev\tests\haxe\LuxeTest\src\Main.hx"@235
-D use_rtti_doc
-D display-details
-main LuxeApp
-D no-compilation
-D web
-D arch-web
-D source-map-content
-D hxcpp_static_std
-D snow_module_audio_howlerjs
-D luxe_web
-D snow_web
-D luxe
-D snow
-cp "C:/HaxeToolkit/haxe/lib/luxe/git/"
-cp "C:/HaxeToolkit/haxe/lib/snow/git/"
-cp "src/"
-resource version@version
-resource build@build
-resource phoenix/defaults/shaders/[email protected]
-resource phoenix/defaults/shaders/[email protected]
-resource phoenix/defaults/shaders/[email protected]
-resource phoenix/defaults/shaders/[email protected]
-resource luxe/defaults/fonts/[email protected]
-resource luxe/defaults/fonts/[email protected]
--macro snow.system.module.Module.set("Audio","snow.core.web.audio.Audio")
--macro snow.system.module.Module.set("IO","snow.core.web.io.IO")
--macro snow.system.module.Module.set("Input","snow.core.web.input.Input")
--macro snow.system.module.Module.set("Windowing","snow.core.web.window.Windowing")
--macro snow.system.module.Module.set("Assets","snow.core.web.assets.Assets")
--macro snow.system.module.Module.set("Audio","snow.modules.howlerjs.Audio")
-cp "bin/web.build/haxe"
-js bin\web\luxe_empty.js 
Main

Completion seem to work if I remove all the --macro commands, but this isn't something that can be done arbitrarily by FD as some macros may be required.

from snowkit-fd.

Thanks for the info,
The interesting thing to me @elsassph is that the --macro parameter will (and should) directly influence the results of the compilation call, because this is what initialization time macros are for.

This is a feature of the compiler, and while I may be able to shield the macros in this specific case - I am not certain that it is a solution as far as FD goes - tomorrow another user macro might break their code completion and they will be stuck again.

Is it possible to debug what the actual error is caused by?
We sort of knew the error was caused by the macro lines given they were in the error message, but removing them for code completion to work feels like a band aid on an actual issue that impedes the ability of FD users to use haxe in a fuller capacity.

EDIT:
I'll be able to debug some things on my windows machine later regarding this as well, to see if that string literal to Class<T> conversion is something that I'm triggering somehow or if it's coming from the FD side.

Ideally we'd have some solution by Ludumdare.

from snowkit-fd.

Ah damn I got it: quotes in the macro expression (when used on the command line) have to escaped!

from snowkit-fd.

That said, it could be good thing to disable unneeded macro processing when you have the completion's display directive set.

from snowkit-fd.

Agreed on the unneeded macros.

That's a good catch!
It seems interesting that it doesn't affect Sublime or Atom or others that hand the same hxml around to Haxe, but I'm glad it's sorted, it looks like it solidifies the experience for FD users a bit further.

One note though, previously I had to remove some spaces from the same macros for FD.
'--macro snow.Module.set("Audio", "snow.core.web.audio.Audio")',
Originally I had a space here. Stripping the space solved a majority of the problems for FD except this one with the quotes, so I'm fairly certain spaces should be escaped too.

Thanks for the help @elsassph,
Are the builds automated for FD?
If I make a write up for users to grab the fixes, is it just the development builds?

from snowkit-fd.

How does autocomplete work with Sublime/Atom? Does it use an hxml?

Indeed all these issues come from the translation from hxml to a single command line (haxe ...) and the Process class takes the arguments as one string and not array of strings so I have to escape the arguments. So I suppose I should add escaping of the spaces as well (committed).

Builds are automated - use development build for latest changes: http://www.flashdevelop.org/community/viewtopic.php?f=9&t=3529

from snowkit-fd.

Yea same way, flow info fetches the hxml.

Here is the way atom is doing this at the moment. I don't recall what my sublime plugin is doing off hand, but I've never had any trouble with the completion there since adding them.

I'd also note, these separated code bases for atom/sublime are falling away atm in favour of a unified parsing/completion/linting library written in Haxe. With python target, we can now target atom in js, sublime in python, and others (c# for example) with the exact same code and have parity across IDE's that can import the code and use it for that purpose. We have a baseline already done in atom, but once we get the unified code up on a repo I'll probably pester you about some insights you may have going forward.

Thanks again for the fix.

from snowkit-fd.

As I supposed, you extract the arguments as an array so you don't have the paths/macro escaping problem. Hopefully we don't find more escaping issues...

from snowkit-fd.