The quest for ooc.vim

👋 This page was last updated ~11 years ago. Just so you know.

I've spent the past few weeks after rock 0.9.8's release working on some of the neglected aspects of ooc, namely tooling support and performance.

My kingdom for a vim plug-in!

Well, technically, ooc.vim is a few years old, and it was even updated a few times to match new ooc features. But unfortunately, so far, it was limited to syntax highlighting.

With encouragement from @happydawn, I decided to take ooc.vim to the next level. @programble was kind enough to transfer the repo over to me so that GitHub would set up redirections, so you lucky boys and girls probably just need to run BundleUpdate! to be up-to-date.

The thing is, to call language support in an editor 'good', you need a few different things... let's review what we have now.

Syntax highlighting

rock 0.9.8 brought us string interpolation, and it would have been a shame to not highlight them correctly in vim. Code inside #{} should be colored as ooc code, not just text data.

Similarly, I recently improved the detection of character escapes in both string literals and character literals. All valid character escapes are now highlighted, whereas invalid ones are left in the cold, default color.

If you're wondering what the VimL code for that looks like, well, here's a taste:

syn match oocEscapedChar display contained "\\\([\\\"\'anrbtfv]\|\o\{1,3}\|x\x\{1,2}\|u\x\{1,4}\)"
syn region oocString start=+L\="+ skip=+\\\\\|\\"+ end=+"+ contains=oocEscapedChar,oocInterpolation,oocNoInterpolation,@Spell

Yup, definitely one of those things you're happy to be done with. Full disclosure: most of it was directly inspired from ruby's syntax highlighting file.

Indentation

One of the things that became second nature when coding ooc in vim, was to always correct indentation by hand. I was using smartindent, but it seems it was not so smart after all.

To be honest, one can't expect a text editor to guess the best indenting practices for your language, even in 2013, so I had to resort going full regex hell mode this time.

It took me a few days to get right, and even then, there are some cases that I consider fixable, but that would make the script too slow on files of 1000+ lines. It is reasonably fast as-is (considered how smart it has to be), I would say it's a good compromise.

That works either directly while typing the code or while reformatting a visual selection, with the = key. One interesting thing about the indentation file is that it's really easy to test. Just feed some 0-indent files to vim, type gg=G in there and compare with a reference output.

Since indent-java was doing it, I figured, why not write a few tests for once and put them on Travis? And so here they are. There could be more testcases, but I did a few iterations where I used large files in rock's source code as examples, and fixed until major fuckups were gone.

Syntax checks

Syntax checking for vim is usually not implemented in the editor itself (as opposed to indentation and syntax highlighting), but rather using external tools. I would have used rock itself, but vim wants to check a single, given file, whereas rock works on entire projects.

Enter sam check, a new command of the sam command-line utility, that is smart enough to find which project a file belongs to, create a dummy .use file, and launch rock on that.

By default, rock will be launched in --onlycheck mode, where it parses the given file and all its imports, then resolve everything, including type delarations, variable accesses, function calls, etc. This gives quite useful errors, as seen above, but can be slow (a few seconds) for big projects like rock - note that syntastic runs a checker on every save by default.

To avoid the cost of a full resolution every time, the g:syntastic_sam_mode option can be set to 'syntax' instead, asking rock (in its 99x branch) to only parse a single file and report only syntax errors - which is nagaqueen's job.

With the syntax mode, check times are reduced to a few milliseconds, which feels instant even for larger files.

Conclusion

For those of you who don't use ooc.vim yet, instructions on how to take full advantage of it are available on its github page. I have also added an editors page on ooc-lang.org for instructions for emacs, TextMate, gtksourceview and pygments. Those could use some love, I would definitely welcome contributions.

I wanted to write more about how I made rock faster so that sam check would run in a reasonable amount of time, and the test suite wasn't so nonchalant, but I guess that will have to wait for another article - perhaps the release of rock 0.9.9!

Comment on /r/fasterthanlime

(JavaScript is required to see this. Or maybe my stuff broke)

Here's another article just for you:

Why is my Rust build so slow?

I've recently come back to an older project of mine (that powers this website), and as I did some maintenance work: upgrade to newer crates, upgrade to a newer rustc, I noticed that my build was taking too damn long!

For me, this is a big issue. Because I juggle a lot of things at any given time, and I have less and less time to just hyperfocus on an issue, I try to make my setup as productive as possible.