Personally, I don't mind using SublimeText, which is my editor of choice for a while. But I'm also curious about commandline editors since many people taut their ability to code over the network. You could forward X or remote in using some other way and still use Sublime, but let's see how if goes.
I started working on this Vim setup when I got a new MBP recently. Figured, I can try something new. So, this post is more of a personal memo written by a total newbie, which is what blogs are all about. caveat emptor. In general though, the configuration is mostly inspired by yuroyoro-san's blog post from a couple years ago.
various non-vim things
The setup described in this post is checked into eed3si9n/dotfiles. It is encouraged to fork other's dotfiles, but I wanted to understand what settings I'm bringing in, so I wrote mine from scratch.
The general idea of the dotfiles is that it will be checked out to ~/dotfiles/, and contains files like zshrc. These root-level configuration files are then symbolically linked under the home directory as ~/.zshrc.
The need for regular expressions is real. Whenver I need to transform a set of text files it usually ends up with fumbling through the documentation of find command, zsh, and StackOverflow Perl questions. I would rather use Scala instead of muddling through Perl. It's really the matter of my familiarity than anything else.
For example, I now have over a hundred reStructuredText files that I want to convert into markdown. I first tried pandoc, and it looked mostly ok. As I was going through the details, however, I noticed that many of the code literals were not converting over as formatted. This is because they were formatted using either single ticks or using Interpreted Text. Preprocessing the text with a series of regex replacements should work.
First, a quote from Programming in Scala, 2nd ed. p. 192:
Scala requires [override] modifier for all members that override a concrete member in a parent class. The modifier is optional if a member implements an abstract member with the same name.
In this post, we'll discuss this "The modififier is optional." Since overriding an existing method with implementation requires override modifier, and failure to do so would result to a compiler error, there's not much to talk about for that case. We'll focus on whether one should put override modifier or not in the case of overring an abtract method. I don't think there's going to be any difference in Scala version, but let's assume the latest stable 2.10.3.