Some points to add:

@Combining Commands
vfa; can also be written as v2fa just to demonstrate that f(ind) and t(o) also take numeric arguments (think of M-2 for the rest of Emacs). Also most other (motion) commands take numeric arguments.

Evil supports text objects so you can also define your di$KEY to delete inside such a text object. (For more see evil-commands.el)

@Defining normal mode commands
From the Merge Request emerged the evil-leader package, to be found here: https://github.com/cofi/evil-leader (I also added it now to the plugins list on emacswiki/Evil)

@My dotfiles
cofi-evil.el depends on cofi-util.el and the cl package, if you copied code and something fails look there ;) (well and the other `require'd packages)

evil-{define,declare}-key support also more than one definition at a time to keep your key bindings clean.

I mapped my CapsLock to Ctrl and use `jk' to exit insert mode (look for cofi/evil-maybe-exit) because this way using other Emacs packages (that sadly never heard about Evil) is way easier. You can also exit insert state via C-[ but that's quite cumbersome.

Last but not least: Evil is discussed at the vim-emulation mailing list also accessible via gmane: http://news.gmane.org/gmane.emacs.vim-emulation that surely should also go into the 'Where you can learn more' list ;)

The reason it's important to think about this is that using some Emacs motion commands while in Evil normal/visual mode results in unexpected or incorrect (usually, in the off-by-one sense) behavior due to the different underlying model of the cursor positioning. Sexp-motion commands are the key culprits here, but there might be others. Ideally, I'd like to see Evil compensating for this difference in behavior (see this discussion), but it's somewhat subtle and I personally don't have a clear conception of how one would do this in such a way as to preserve behavior that's sensible for Emacs without breaking Vim commands.

(Alternatively, someone could tell me how to navigate through code in Evil effectively without resorting to sexp-motions. I have found them to be very handy, and I know seasoned Emacs users that swear by them for any sort of code navigation.)

One minor possibly pedantic point: I would argue that there is no asymmetry in how Emacs handles selections. The key difference between Emacs and vi is that in emacs the position is always "between" characters where in vi it is "on" a character. For this reason, I have always set the cursor in Emacs to be a vertical bar to highlight this aspect. When using evil, I keep the cursor as a block. The difference positioning between the modes is then made visually clear.

Thanks again!

2. SO is awesome. I'm on it. Furthermore, it is another reason for why moderation on Mathgroup is completely unnecessary: newbies can get their questions answered on SO, while the more sophisticated crowd can engage with Mathgroup luminaries.

3. Yes, having plots be very general is, in principle, desirable. Unfortunately, without a good interface (something akin to what Matlab provides) this generality is useless. I recently spent a whole day (!) reformatting a single plot to prepare it for publication. Manually changing line styles and fonts by constructing complex pattern-based replacement expressions, but that was the easy part. MMA PDF export is spectacularly bad: it's anything but WYSIWYG and requires much trial and error to get right. Next time I'm doing this in Inkscape.

1. MathGroup is moderated by a single guy, and he isn't paid to do it. Yikes. I've also had references to other CAS systems and Matlab censored --- and received an email explaining why, which was nice. Basically, past flame wars lead the volunteer moderator to adopt the do-not-mention policy. Annoying, but I understand the time and energy this must save him.

2. You should join StackOverflow.com, if you haven't already done so. It is a much better/faster place to get MMA help, and the site is set up to publicly reward the best answers, good questions, and useful comments with reputation points.

One final thought, about plotting in MMA, which you mentioned in another post...

I agree that it can be a PITA sometimes to get things to look right, but plotting functions seem to fit the MMA design pattern of 'make things as general as possible'. Hopefully things will continue to improve---as I'm sure they will---given that all the Wolfram|Alpha plots are produced by Mathematica in the background (and they look great, IMO).

If you've upgraded to version 8, you might try using the link to Wolfram|Alpha; send it your data, have it generate the plot, and then just grab that 'pod' of W|A output.

The Demonstrations Project is also good source of plot customization code and examples.

GIMP (open source) alternative to Photoshop may also be able to handle the necessary post processing, if you're sick of trying to code perfection in MMA.

:)

But comparing a true symbolic calculation engine against a purely numeric one is rather unfair. You can add extra effort to ask Mathematica to treat your input as purely numeric (like NIntegrate), but good luck getting Matlab to do some of the fascinating things that Mathematica can do out of the box (even if they take a bit of time, because a symbol's representation and checking its various values under various conditions takes longer).