test is failing. if you have interesting this change, I'll fix.

I tried rake on my environment. But not reproduced.

mattn@tiger:~/.vim/plugged/editorconfig-vim/tests$ ls
Gemfile  Gemfile.lock  Rakefile  spec
mattn@tiger:~/.vim/plugged/editorconfig-vim/tests$ rake
/usr/bin/ruby1.9.1 -S rspec ./spec/editorconfig_spec.rb
..............

Finished in 6.74 seconds
14 examples, 0 failures

@mattn Thanks for the PR.

The plugin tests aren't really complete. If you meant to write a parser in vimscript, you would probably need to run the core tests separately...

Do you have a reason to remove python dependency? Because we want to reduce the number of EditorConfig core implementation as much as possible to make sure the development of cores would not lag too much whenever a new feature comes into our mind. Therefore, whenever a new core implementation does not bring too much benefit, we don't want to do it, or at least not to enforce it (in the case it may die).

Anyway, can you give a reason to remove the Python dependency? We may have an alternative solution for it.

• One reason I can think of is the lack of Python on Windows. In this case, we can bundle a Windows editorconfig.exe.
• If it's the Vim builtin python issue, I feel comfortable to remove the embedded python code but we can still call the python executable to execute main.py in the editorconfig-core-py directory.

Given the assumption that non-Windows systems have Python installed by default, it should virtually have no external dependency, i.e., requirement to install any additional packages.

At the first, I'm guessing the part of editconfig used from vim script is smaller than we are thinking. Just to get dictionary of configuration. But:

• we have to bundle bigger modules
• codes for detecting few version of pythons
• requirement python or editconfig.exe or if_python

So I implemented vim script version of parser. This will works fine on users who doesn't have vim with if_python.

one more thing.

function! s:foo()
python <<EOF
a = 1
EOF
endfunction

function! s:boo()
python <<EOF
print a
EOF
endfunction

call s:foo()
call s:boo()

if_python contaminate global variables. if call :py foo.py from vim script. it makes global variables.

If your opinion is that if_python is evil, yes I agree we can remove it in a future version, thus only reply on external python interpreter or any editorconfig executable. IMO, my suggestion listed in the first comment can solve this problem. Also, we wrote the embedded python code very carefully to not contaminate the global variables.

Now the question is whether it is worth the maintenance of the vimscript version core if we soly want to reduce the size. The current plugin size is less than 500K, which is already super small for modern hardware, thus I don't think it really worth the effort. What do you think?

In my opinion, for example, java app used java library https://github.com/editorconfig/editorconfig-core-java. And vim can use vim script to do it.

@mattn If you can make the vimscript version a fallback solution, i.e., still allow people to use the other more supported core implementation, we can accept it. This would be the same case as Emacs.

Editorconfig seems to be small enough as a specification. In my opinion it would be good to have a native vim implementation. If editorconfig is used with vim then people will file issues soon enough.

In the current situation installing a c binary for a vim-plugin is just too much work for me. So I agree with @mattn that it is a hurdle for the editorconfig vim-plugin.

Discussion underway at editorconfig/editorconfig#383 and vim/vim#2286 - https://github.com/cxw42/editorconfig-core-vimscript/ and https://github.com/cxw42/editorconfig-vim/tree/vimcore are another way to accomplish this.

Edit vimcore now has the Vim core and plugin together in one package, with no Python dependencies.