Completion support for NME projects
dean-nicholls opened this issue · 34 comments
Hi,
I've installed vaxe and it seems to run great with standard hxml based projects. However I work quite a lot with Haxe NME and it would be awesome to have this plugin be compatible.
So far I've been changing directory to my project root directory, then setting ":ProjectHxml" and selecting the "bin/flash/haxe/debug.hxml" file.
The main issue seems to be with vaxe not playing well with the hxml file generated by NME. For example the "-swf-version 10" line seems to cause a compiler error on any line below it, but removing this line gives the error "Compiler error: Error : No completion point was found ".
I suppose this is more of a feature request than an issue, since you dont seem to mention NME anywhere, but it would be awesome to support NME since it's possibly the most important haxelib available (though that's subjective I guess).
I'm pretty new to vim and vim-plugins but I'd be more than willing to help with adding this support in any way I can :)
EDIT:
Just noticed that removing the offending "-swf-version 10" line will get the Ctags support working.
EDIT 2:
Scratch that, Tagbar is working, but the vaxe#ImportClass() is not.
Sure, I'll check into this. I don't have any NME projects at present, but there's no reason it shouldn't work.
I did find the bug here, thanks for the heads up. Let me know how the NME development setup works for you.
Thats great, pointing vaxe to the hxml file generated by flash works, I get completion and class importing. However to get this working I had to remove all spaces from the filename (changing the hxml to produce 'MyGame.swf' as opposed to 'My Game.swf') and I had to change the initial Sprite class from an nme.display.Sprite to a flash.display.Sprite.
Small price to pay though :)
Thanks Justin
I can look into the issue with the space. I convert the hxml file into a simple set of arguments, and haxe handles spaces differently on the command line.
You shouldn't have to change the nme/flash classes, nme should function identically as far as I know. Is vaxe not working for a simple tutorial example?
Hi,
I've created a very simple sample project to show this. You can download it here:
https://dl.dropbox.com/u/7393360/vaxetest2.zip
In this example, after I set the :ProjectHxml to be bin/flash/haxe/debug.hxml, entering "mc." and triggering autocompletion (at Test.hx line 12) will result in a message saying "Compiler Error: Error: No completion point was found".
If I change the import for Sprite in Test.hx from nme.display.Sprite to flash.display.Sprite and then trigger autocompletion, everything works as it should.
Hope this helps :)
Thanks for the example. Try one more thing... ProjectHxml needs to be called from wherever you'd normally trigger the compiler command. I've changed a bit how ProjectHxml works, so now you can call it anywhere. Try opening vim on the project root, and calling it. I think the rest of the directory issues should sort themselves out. You should see this:
http://imgur.com/15ima
Your project structure looks a bit strange to me. I normally would put hxml files in the root of the project, and hx files in the src, or maybe in lib. I'm not familiar with nme, or your workflow though.
I'll give that a go when I get home later, thanks :)
The location of the .hxml file is chosen by nme, with nme projects you create a .nmml file which is an xml file describing the settings for the app. When you build the project (using 'nme build application.nmml flash' for example) a .hxml file along with some extra .hx files are created in the bin/flash/haxe folder, which is what you're seeing in the example project.
The folder structure is what's recommended by nme, and what is auto generated when using an ide (such as flashdevelop or monodevelop) to create nme projects.
That's good to know then. I'll see about making vaxe more nme-aware.
What is the current state of NME support? The readme mentions that Vaxe supports NME project files, but I can't figure out how set it up. When opening a Haxe file from one of the samples projects included in NME I get the following error message: "Default build file not valid: "/path/to/project/Source/".
NME is still early on, so there's still some rough edges. I've changed the way that vaxe searches parent directories for nmml files. Can you update vaxe and give it another try? It should be able to figure out the nmml and build directory on its own.
Building with ":make" works great now! No omnicompletion tough.
Ok, well that's progress I think.
I think I see where the problem might be. I've made another push, can you try updating again?
Definitely progress 👍
It's still not working here. Sorry.
ok, can you check and see if there's a *.nmml.hxml file in the root of the project? Does it have anything in it?
I'm guessing that might have been generated by an earlier buggy method in vaxe.
Anyways, I've pushed another update that should force the nmml.hxml file to update, along with adding a warning on top. Give it another try whenever you can, and thanks for your patience.
I'm testing with the samples in NME. And there's a .nmml file which should be fine. I still can't get anything but "Omni completion (^O^N^P) The only match" out of the omnicompletion though.
I've pushed a few more updates, mainly adding a few more file name escape guards. Are you having problems with really simple projects, like the one posted by @dean-nicholls?
https://dl.dropbox.com/u/7393360/vaxetest2.zip
That one works fine for me.
So, I would try the following steps:
- make sure that the bundle is updated (Vundle's :BundleUpdate command should do this)
- open a file somewhere in the nmml project
- you should see a dialog asking you for a nme target (e.g. flash, cpp, etc). I'm assuming this works since you can build.
- make sure the nmml file was detected:
:echo g:vaxe_nmml - make sure that the nmml.hxml file was created, and is being used:
:echo vaxe#CurrentBuild()
(it should list a name of a file with an nmml.hxml extension, and you should be able to open it and see some hxml directives) - set logging:
:let g:vaxe_logging=1 - trigger an omnicompletion somewhere in the code
- open your message console, and send me a note with what it says:
:mess
also let me know if you're using osx/windows/linux/etc.
Thanks again, this is a somewhat complicated thing to get right on all of the vim platforms, your help is appreciated.
Here's what those steps produce for me (completion also not working).
haxe -main ApplicationMain -lib nme -lib HaxePunk -cp src -cp /usr/lib/haxe/lib/nme/3,5,5/ -cp /usr/lib/haxe/lib/HaxePunk/2,1,1/ -D nme_install_tool -D web -swf-version 11 -swf9
bin/flash/bin/ApplicationMain.swf -swf-header 720:480:60:333333 -cp bin/flash/haxe --display /home/dsirijus/Desktop/Projects/vizard/src/ApplicationMain.hx@177 2>&1
(1 of 1): Error : No completion point was found
Can you run that hxml from the command line at the project root? What about running it without the --display command, does it compile?
(without --display:)
haxe -main ApplicationMain -lib nme -lib HaxePunk -cp src -cp /usr/lib/haxe/lib/nme/3,5,5/ -cp /usr/lib/haxe/lib/HaxePunk/2,1,1/ -D nme_install_tool -D web -swf-version 11 -swf9
bin/flash/bin/ApplicationMain.swf -swf-header 720:480:60:333333 -cp bin/flash/haxe
If that compiles correctly, then I think there is something wrong with the @177 number. Maybe I'm not handling certain encodings correctly.
Yes, it compiles correctly that way, no messages.
Can I bother you to try a few more things? I think I'm making a mistake in how I'm calculating the offset (e.g. @177 in your case). It's really tricky for me to track down since vim seems to calculate this number differently in some cases.
So, try invoking completion really early in the file, after the first package of the first import on the first line:
#Test.hx
import haxe.|
[...]
In this case, the completion point should be @12 at the caret (|), since it is 12 characters away from the start of the file. Can you check the log to see if this is the case?
That sure looks right to me.
I do my best to detect the BOM, which can sometimes add hidden bytes to the beginning of the file, but I don't know what else would mess up the offset in this case:
http://en.wikipedia.org/wiki/Byte_order_mark
I'm going to try a different approach at determining offset... something more vim-specific.
Ah, another thing I changed... I no longer autowrite the file during completions. It's necessary for you to save manually, or set a relevant option. I'm wondering if this could be the case?
:set autowrite
If that is set I will autowrite whenever you request an autocompletion. This can of course be specific to haxe files only:
au FileType haxe setl autowrite
No, this didn't help.
Maybe it's relevant, here's my .vimrc - https://gist.github.com/dsirijus/127c9b5053323ddc751e
I still got everything to work after just using your .vimrc, and vundle (with no extra plugins).
I'm thinking it has to be a BOM issue. If you could tell me what these settings show when you have ApplicationMain open, it would help:
:echo &bomb
:echo &encoding
:echo &fileencoding
:echo &fileformat
If you really wanted to nuke this problem, you could try to run the completion hxml a few times at different offsets. E.g. change the offset to @{10,11,13,14,15} and re-run it for each value. I just want to see if you can get the xml output from --display to show up, and then work out why the offset differs from what it seems like it should be. This example should be dead simple. E.g. just change the @12 offset to @13, @14, etc.:
haxe -main ApplicationMain [...] --display /home/dsirijus/Projects/vizard/src/ApplicationMain.hx@13 2>&1
Those are the only other things I know of that could affect document bytes outside of visible characters.
:echo &bomb 0
:echo &encoding utf-8
:echo &fileencoding utf-8
:echo &fileformat unix
I'm not sure is this what you've asked for, but changing @11 in the following command to increased values gives same output:
haxe -main ApplicationMain -lib nme -lib HaxePunk -cp src -cp /usr/lib/haxe/lib/nme/3,5,5/ -cp /usr/lib/haxe/lib/HaxePunk/2,1,1/ -D nme_install_tool -D web -swf-version 11 -swf9 bin/flash/bin/ApplicationMain.swf -swf-header 720:480:60:333333 -cp bin/flash/haxe --display /home/dsirijus/Projects/vizard/src/ApplicationMain.hx@11 2>&1
(1 of 1): Error : No completion point was found
Can you drop by the #haxe or #NME IRC channel?
http://haxe.org/com/meeting/irc
I think we can finally mark this issue as dead...
For future googlers: NME by default will create a Main.hx file for you, but will reference a ApplicationMain.hx file in the hxml. The ApplicationMain.hx file is actually located in the bin//ApplicationMain.hx in the project directory, and contains boilerplate code for initializing the given target.
You don't want to alter any of the files in that bin directory, nor do you want to change the name of the Main.hx file to ApplicationMain.hx, or else bad things will happen; Broken completions included.
Also, to my shame, one obvious bit - have vim with python support.
Just in case this helps anyone else who finds this thread. I had the same issue as @dsirijus with (1 of 1): Error : No completion point was found and setting vim to autowrite with set autowrite fixed it.
Plus the autowrite really helps with the awful 2-5 second save time I was getting when saving manually. Along those lines, any idea why vim locks up for 3 second when first opening a file?
Thanks for the note. I'll add a check (and warning) if the user doesn't have set autowrite enabled. Technically, the plugin will still work. But, you'll need to save the file manually, and then retrigger the omnicomplete.
I've looked into how to avoid writing a file during autocompletion, since I suppose in a few cases a user may not want to save the file. But, it's not a simple solution.
I should also note that I just ran into an issue where the auto complete through the same error when attempting to be used within an interpolated string. I haven't confirmed if this is just in my project or everywhere, but at any rate it sounds like an edge case that would come up eventually.
Thanks...yeah, I can catch those. Try updating the plugin once again, you shouldn't see that happen any more.
P.s., I also think i've found a way to speed up the plugin on an initial load as well.
@jdonaldson Yah, that makes it much faster. Thanks for the fast updates and the great job with the plugin!