ImportClass seems to work only when the package is provided

[wighawag]

In the doc I read

calling vaxe#ImportClass on this line:

var l = new FastList<Int>();

will generate:

import haxe.FastList;
...
var l = new FastList<Int>();

but when I try (using haxe 3) with the following line:

var l = new StringMap();

it fails with an error saying that it doe snot find StringMap in the ctags

but when I use:

var l = new haxe.ds.StringMap();

it remore "haxe.ds" and add an import for StringMap;

Note: I called vaxe#Ctags() before

By the way, Do I need to call vaxe#Ctags() or the vaxe plugin call it automatically ? If not should I add it to my ~/.vimrc to be triggered in some way?

Thanks for this vaxe plugin. It is really awesome, though I still need lots of practice (a vim newbie)

[jdonaldson]

I haven't looked at ctags and Haxe 3 yet... I should have an opportunity soon.

[jdonaldson]

I just pushed a few more fixes to the importClass method. One of the important ones is actually a change to the recommended ctags file, which you can see in the README. It fixes a small package issue. You can also see if updating helps in your case, but I kind of doubt it.

It sounds like you have a more general problem, since it doesn't seem that ctags is producing a tags file. The simple solution is just to try and run ctags from the root of the directory. You can generate the actual ctags command used from within vaxe by turning on login (let g:vaxe_logging=1 or using the new :ToggleVaxeLogging command). This will dump the ctags command to the :message list.

Here's what one of mine looks like:

cd /Users/jdonaldson/Scratch/Tut01; ctags --languages=haxe --exclude=_std -R /u sr/lib/haxe/lib/nme/3,5,5/ bin/flash/haxe/ /usr/lib/haxe/std/flash/ /usr/lib/ha xe/lib/HaxePunk/2,2,0/ src/ /usr/lib/haxe/std/haxe/ /usr/lib/haxe/std/sys/ /usr/ lib/haxe/std/tools/ /usr/lib/haxe/std/*.hx;

You can run a similar command from the terminal, and it should generate a tags file for you. If it doesn't, perhaps there's something in the command that will help pinpoint a problem.

[jdonaldson]

Also, to answer an old question in your first comment, yes you do need to run vaxe#Ctags() (or the command :HaxeCtags). If you're missing a package name, vaxe has to look through all of the package names in the ctags file in order to find a candidate.

[wighawag]

Sorry to bother you but I could not manage to get the command executed by vaxe plugin regarding ctags

I executed vim with the following command and then search for "Error" in the log file

vim -V9<log filename> <filename>

I found the following error 5 times :

Error detected while processing function vaxe#AutomaticHxml..vaxe#DefaultHxml..<SNR>152_BuildNmmlHxml..vaxe#NmeTarget:
line    6:
E684: list index out of range: 0
E15: Invalid expression: split(g:vaxe_nme_target, ":")[0]

then there was this error

Error detected while processing /home/wighawag/.vim/bundle/vaxe/compiler/haxe.vim:
line   10:
Interrupted

then this one:

Error detected while processing /home/wighawag/.vim/bundle/vaxe/ftplugin/haxe.vim:
line    1:
Interrupted

and finally after I toggle logging for vaxe and execute HaxeCtags manually I got

 Error detected while processing function vaxe#Ctags..vaxe#CompilerClassPaths:
line   13:
The compiler exited with an error: Haxe Compiler 3.0.0 - (C)2005-2013 Haxe Foundation

Not sure what is wrong.

Since I have a very slow connection (mobile phone 2G) and I did not found a way to tell Vundle to update only 1 specific bundle, I updated your plugin via :

git pull

Maybe this is not a good way of doing ?

[jdonaldson]

Looking into this... is there a good nmml.hxml file for your project? I.e. does it have sensible compiler flags in there?

[wighawag]

Ok just a quick info, I ll send you more later when I ll have more time:

I have some error on a nmml project which is in a subdirectory. I am actually using NME tools/run-scripts

So if you have NME source you might try it yourself

cd tool/run-scripts
vim src/RunScript.hx
:HaxeCtags

Regarding hxml project I ll have a go later to see whether HaxeCtags works properly (it at leats does not produce errors here)

Thanks

[wighawag]

Just add a deeper look and the error regarding ctags with compiler output is also present in simple hxml project

Somehow I got a beter log and I see that:

finished sourcing /home/wighawag/.vim/bundle/tagbar/autoload/tagbar.vim
Calling shell to execute: "('ctags' --version) >/tmp/vqPOG02/10 2>&1"
Calling shell to execute: "('ctags' --list-languages) >/tmp/vqPOG02/11 2>&1"
chdir(src)
fchdir() to previous dir
Calling shell to execute: "('ctags' '-f' '-' '--format=2' '--excmd=pattern' '--fields=nksSa' '--extra=' '--sort=yes' '--language-force=haxe' '--haxe-kinds=ceitvf' '/tmp/vqPOG02/12.hx') >/tmp/vqPOG02/13 2>&1"
chdir(src)
fchdir() to previous dir
chdir(src)
fchdir() to previous dir

Calling shell to execute: "(cd /home/wighawag/SDKs/haxenme/NME; haxe -v --no-output 2>&1) >/tmp/vqPOG02/14 2>&1"
                                                                                                                Error detected while processing function vaxe#Ctags..vaxe#CompilerClassPaths:
line   13:
The compiler exited with an error: Haxe Compiler 3.0.0 - (C)2005-2013 Haxe Foundation
chdir(src)

So it seems that it fails because haxe -v --no-output is not sufficient to produce anything in the NME directory. It needs haxe -main <class> <output> at least

It is maybe somethign new with haxe 3?

Regarding nme project I get this error as show in the last message:

Error detected while processing function vaxe#AutomaticHxml..vaxe#DefaultHxml..<SNR>152_BuildNmmlHxml..vaxe#NmeTarget:
line    6:
E684: list index out of range: 0
E15: Invalid expression: split(g:vaxe_nme_target, ":")[0]

And if I execute vim without any path and then read a file in a nme project, I got lots of error and I have to do Ctrl-C to stop and then :q to quit vim Tested with NME/tools/run-script/src/RunScript.hx

[jdonaldson]

I think the problem is that there's not a valid hxml file. I use the compiler (plus the hxml file) to tell me path information for the standard haxe libraries, in addition to haxelibs, extra classpaths, etc.

I could do a simpler version that just uses the current working directory... but it would be missing a lot of references. Would that still be useful?

At the very least, I could add an error/warning message about the missing hxml.

[wighawag]

Sorry, probably got confused after testing with several different projects,

For the simple hxml project it indeed work, I forgot to look at the status line It indeed showed [Bad Hxml] that was fixed after I called :DefaultHxml test.hxml

Maybe it would be better if Vaxe look for any hxml in the current and then parent directory

I had only one "test.hxml" in this case (for haxe since libraries are source only, I normally have only tests and no "project/artifact" to generate)

And maybe if there are several hxml files, Vaxe could ask which one to use (the same way it ask for platform in nmml project )?

+1 to show unexpected error ([Bad Hxml] was good though, if it could be colored that would be even better)

For the nmml project if it also look only for specific nmml file name, maybe it should also look for any nmml ?

Thanks for your help

[wighawag]

I just retested my nme project (the tools/run-script folder in NME source code and I know understand the problem:

Vaxe, instead of linking to the hxml file in the current directory (RunScript.hxml) it links to ../../include.nmml (the first nmml file found) which is in fact a nmml for an extension

<?xml version="1.0" encoding="utf-8"?>
<extension>

        <ndll name="std" haxelib="hxcpp" />
        <ndll name="regexp" haxelib="hxcpp" />
        <ndll name="zlib" haxelib="hxcpp" />
        <ndll name="nme" />
        <ndll name="libfreetype" register="false" if="emscripten" />

        <haxedef name="nme" />
        <templatePath name="templates/default" />

</extension>

from this Vaxe generate an empty include.nmml.hxml

I could fix it by calling :ProjectHxml RunScript.hxml

So maybe Vaxe should check the vailidity of the nmml file beforehand or check its generated hxml ?

[jdonaldson]

Yes, the default is to always use the nmml. If you have a complex build environment with multiple hxml/nmml files, it's often useful to include the currently used hxml path in your statusline, in order to be aware of what you are building: :autocmd BufNewFile,BufRead *.hx set statusline+=\ build:\ %{vaxe#CurrentBuild()}

My vim-powerline bundle branch will do this for you.

If you want to have specific hxml files for certain working directories, you might want to look into setting vaxe variables (let g:vaxe_hxml=/path/to/build.hxml) in a local vim configuration: http://stackoverflow.com/questions/1889602/multiple-vim-configurations

It's difficult to figure out which hxml/nmml is best for a given project. If you have ideas on this, I'd be happy to hear them.

[wighawag]

Hi Justin

I actually use a copy of your own .vimrc :)

Thanks for the hint on local vim config but I think I would prefer some auto configuration from Vaxe. For now I do not use session as I want to learn vim first but I guess when session is saved, I would not need to re set Vaxe project settings again.

Regarding hxml/nmml detection, I would suggest the following:

setp 1) First look at directory which the source is located, If you find an nmml, go to step 2) if you find a hxml fo to step 3) if no thing found, repeat step 1) at the parent directory (in other word, hxml file take precedence over nmml file when in a directory deeper)

step2) nmml file found if several nmml files are found, ask which one to use (if that is difficult to achieve, maybe use some preferences variable as Vaxe currently do, right?)

step3) hxml file found if several hxml files are found, ask which one to use (if that is difficult to achieve, maybe use some preferences variable as Vaxe currently do, right?)

step 4) parse the hxml/nmml file and check whether it is valid (not sure how to easily check validity?) if not , try the next hxml/nmml file using step 2/3 or if only 1 file was present, step 1 if no valid hxml or nmml found, show error message

alternative : step 4 could show error message at first attempt and not try other files other alternative : do not check. if the nmml/hxml is wrong then, it is wrong and Vaxe cannot do anything about it.

I guess the main difference between the suggestion and the way Vaxe currently work is:

• hxml take precedence over nmml if in a directory deeper
• look for any hxml file name and only when multiples are found does it ask for preferences

The reason behind this suggestion is so that vim+vaxe can work in most project without user intervention. It also do not dictate file name for hxml and nmml files.

But now that I understand more how Vaxe/vim works, I probably can work with how Vaxe handle it currently. This suggestion would probably be useful for newcomer (like I was) though.

By the way you said :

Also, to answer an old question in your first comment, yes you do need to run vaxe#Ctags() (or the command :HaxeCtags). If you're missing a package name, vaxe has to look through all of the package names in the ctags file in order to find a candidate.

I don't understand why vaxe could not call it as soon as it find the correct hxml/nmml file ? Is it not achievable with some .vimrc magic?

Thanks for this great piece of work!

[jdonaldson]

Thanks for the detailed comments. I'll see about enabling a better, more configurable hxml/nmml default detection routine. I don't think there's a default that works best for everyone. But, I can see how the current defaults don't suit some people. I think I can settle this through configuration.

A few more comments/questions:

Did you get the ctags to work, once you had the hxml right?

Regarding auto-ctags: I could call the ctags creation file automatically. However, ctags creation can take some time, especially for larger NME projects. It would be nice to handle this asynchronously, but unfortunately getting this to work right in vim is complicated. There are some plugins I could support I suppose. At the very least, I'll try to enable this through a configuration variable.

p.s. I somehow missed your comment about [Bad Hxml], you don't need to set statusline if you're already using my vimrc, etc. If that's the case, nevermind that suggestion, you already have a better solution for that.

[wighawag]

I agree that no configuration will work for everyyone, but I feel that name of nmml/hxml file should not matter if there are only one of such hxml file and that deeper directory should always take precedence. But maybe this is again just me :)

Yes the ctags works fine now, even for ImportClass.

Your vimrc have probably saved me lots of time. vim looks quite nice with your selection of plugins :)

Thanks again for your help. This is a great editor and I say that coming from IntelliJ Idea :)

[jdonaldson]

Thanks! Glad to hear it works for you. I'll have more time later this week to add some more configuration and features, stay tuned!

[jdonaldson]

I added some more options for managing how default hxml/nmml files are found and used. The default now will search recursively through parent directories for both nmml and hxml files. However, you can easily choose which format (nmml or hxml) gets precedence, whether the hxml/nmml file should be named something specific (e.g. build.hxml, or *.nmml), and if vaxe should just use the first one it finds (on a given directory), or ask you which one it should use. Let me know if the options/usage is clear.

Check this excerpt from the docs:

_g:vaxe_preferhxml The name of the hxml file/glob to search for and use automatically. The default is "build.hxml".

_g:vaxe_prefernmml The name of the nmml file/glob to search for and use automatically. The default is "*.nmml".

_g:vaxe_prefer_first_indirectory When vaxe finds more than one build file in a directory, setting this variable to 1 will make vaxe always choose the first one. If it is set to 0, then it will present a list of options. The default is 1.

_g:vaxe_default_parent_searchpatterns This is a list of |glob| patterns that vaxe uses to determine which hxml (or nmml) file to use on startup. The default is:

[g:vaxe_prefer_nmml, g:vaxe_prefer_hxml] <

                    Note that vaxe will search recursively through
                    each parent directory, and stop at the first file that
                    matches the pattern.  E.g., by default, vaxe will
                    recursively look for *any* nmml file, or one called
                    'build.hxml'.  It will give precedence to the nmml file,
                    since it occurs before the hxml file in the search
                    pattern list.