Pyro Chub

Stop reading right now if you don’t care about Vi or Vim.

I use Vim primarily because it’s available on both Linux and Mac OS, (using the really cool MacVim program).

One of the most annoying features of Vim (go ahead and insert your own Vim slam here) is where it places the cursor when you exit insert mode.  Vim always wants to put the cursor on the last character you typed.

For example, I have a line containing:

foo bar baz

I change “bar” to “quk”, then press escape.  My cursor is now on the “k” in “quk”

foo quk baz

So, if I want do delete “quk” or “baz”, I have to move the cursor to the right by one character.  As petty as this sounds, it continuously gets in my way when I’m editing code.  This behavior is especially awkward when dealing with parenthesis or brackets in programming.  I would much rather have the cursor stay on the space that’s after the “quk”.  That way, I can use “db” or “dw” to delete the previous word or the next word, without deleting the “k” that at the end of “quk”.

Here’s a Vim script that I found which does just that:

vim-insert-mode-fix.vim

Put this file in your ~/.vim/plugin directory and restart Vim, and see if you like the difference.

A word of warning:  This script affects a pretty basic Vim feature, and might have an effect on your existing Vim scripts.  You’ve been warned.  I haven’t used it much, but it seems to do exactly what I want.

There’s also some hacks for leaving insert mode when your cursor is at the **end** of a line, but I’m happy with this script for now, and don’t want to bit off more than I can chew.  Thanks to Nikolai Weibull for this script.  I’ve been searching quite awhile for this, and I hope someone else finds it handy.

If you do any work in a Unix/Linux terminal, you need to know about the Escape-Period shortcut.

It’s similar to using the up arrow to get a previous command, but it only returns the last word instead of the whole command.

Without further ado, I’ll show you what’s up.  Let’s say you move some file to /some/long/directory/name.  Then, you want to go to that directory.  Escape period is your friend.

mv myfile.txt some/long/directory/name
cd <ESC><Period>

You should now be in some/long/directory/name

Make sense?

You can keep pressing Escape-Period, and you’ll cycle through the previous arguments to your commands.

Hope this helps!

–Nate

In Grails, I often encounter large, menacing stack dumps that seem to tell me I’m using incorrect parameters when calling a method.  For example:

My test code contains a simple method call:

myService.getThing(foo, bar)

But when I run my tests, I see this error at the top of the stack trace:

No signature of method: MyService.getThing() is applicable for argument types: (Foo, Bar)
values: {foovalue, barvalue}

To me, the above message implies that I have a problem with the arguments that I’m passing.

Before I wheel in the yaks and the razors, I do two things:

1. Make sure there’s actually a getThing method in the class that I’m calling.
2. Check the spelling, pluralization, and capitalization of the method name.
3. A  Grails developer commented below to run the grails clean command.  I agree.  I have been able to fix some hard-to find problems by merely running grails clean in your project’s root directory.  Thanks for the suggestion!

As it turns out, MyService had a method called getThing(s) — D’oh!

class MyService {
    def getThings(foo, bar) { // <- plural "Things" -- whoops!
   }
}

To be fair, Grails is correctly reporting the problem.  There really is no method called getThing(Foo, Bar).  I do think the message is a bit misleading in this particular case.

Maybe future versions of Groovy/Grails could be able to differentiate between (in my opinion) what seem to be two different problems.  I’ve spoken with a Groovy expert about this request, and it wouldn’t be as easy as it sounds.

So until then, use this methodology:

1. Start Simple:  Check spelling, capitalization, and pluralization
2. Make sure you’re calling the correct class.  Make sure you’re calling Foo.someMethod(), and not Bar.someMethod()
3. Try the grails clean command.
4. Try to code only a few lines at a time before running/testing the application.
5. Go to the nearest bar.  Bartenders are a really good substitute for the “Rubber Duck” solution.

Good luck!

–Nate