This makes sense, @davidzchen since you've been dealing with style-related issues would you like to review before I merge?

Don't waste your time reviewing it just yet. I'll soon make a pull request with a complete style guide. That is, I've taken Google's cppstyle.xml, removed the C++ stuff, and included our changes. If we can agree on that style, we are in a good position to clean up clint.py even more.

clint.py is still taking an awfull lot of time, about 1 minute to lint the whole source and 4 seconds to lint eval.c. I'm playing with the thought of rewriting it in C eventually.

@mahkoh 1 minute is not bad considering that it's travis job to lint every source file after a push.

As for eval.c, I hope we can remove such abominations eventually(see lua-related plans). @philix is already doing a great job spliting files(#209). In time we'll be able to run clint.py on any file without significant delays.

Still, I wouldn't want to push anything without having run all tests, unittests, and linters locally first. neovim already takes a non-trivial time to build. Being able to subtract one minute from that would be great.

A rewrite would also give us the opportunity to turn it into a neovim plugin à la syntastic.

I think the bulk of the build time for Neovim is not in building Neovim itself but building all the dependencies. We might want to revisit whether we want to move the dependencies out of the source tree and provide instructions for the developer to install dependencies instead.

It would be awesome to make the lint tool into a plugin in the future. In the meantime, I agree with @tarruda that adding 1 minute is not too bad for now.

I'll review your changes once you have them ready. Thanks for your help, @mahkoh!

@davidzchen check the wiki . i added a link to a gist to use the linter as syntastic checker. That's working nicely for me.

It would be awesome to make the lint tool into a plugin in the future. In the meantime, I agree with @tarruda that adding 1 minute is not too bad for now.

That's even more true now that I've re-enabled valgrind on travis. Running all the tests takes at least 25 minutes but prevent future problems like #312

  Is there a way to enforce the lint tool in Git? In other words, is it

possible that once someone pulls the source, they also pull a git
pre-commit hook that runs the lint tool? Or is this bad Git practice?

  Also, why are you worried about the speed of running the lint tool on

the entire repo? In a git pre-commit hook you would only need to lint any
files that have been changed. You could even take it a step further and
only lint lines that were changed in the commit. Obviously the latter would
only work if you knew all your code base as already linted properly.

On Fri, Mar 7, 2014 at 2:46 AM, Thiago de Arruda
notifications@github.comwrote:

It would be awesome to make the lint tool into a plugin in the future. In
the meantime, I agree with @tarruda https://github.com/tarruda that
adding 1 minute is not too bad for now.

That's even more true now that I've re-enabled valgrind on travis. Running
all the tests takes at least 25 minutes but prevent future problems like
#312 #312

Reply to this email directly or view it on GitHubhttps://github.com//pull/302#issuecomment-37020854
.

I'm done for now.

why are you worried about the speed

Gotta go fast.

Looks great 👍

@mahkoh 👍 LGTM. This is ready to merge, isn't it? Could you label as RDY?

I will merge this now. if @mahkoh wants to make further modifications he can open another PR

Merged, ty for this @mahkoh

There are a few more things you can remove if you want:

$ vulture clint.py
clint.py:878: Unused class '_IncludeError'
clint.py:964: Unused function 'NoExtension'
clint.py:968: Unused function 'IsSource'
clint.py:1711: Unused attribute 'is_derived'