codemonkey like you

Month: September, 2010

A tiny bit of Vim

I’m trying to reorganize my monolithic zshrc into discrete files, so I was putting e.g. all the setopt commands in ~/.zsh/opts, and I discovered a neat thing.
You can visually select a chunk of text, do :w file_name, and Vim will create a new file named file_name, with just the selected text in it, while leaving you in your original file.
I just discovered this. My thought process: “I only want to write out part of this file…I’ve heard Vim is kind of like a language for text editing, so let’s see if this works…YES! IT WORKS!” And then I stared at the screen in wonder. No, really. For like 10 seconds, just staring.

Vim is pretty awesome.


How to get ZSH to complete CMD1 like CMD2

I tested out git-achievements (my achievements are here), and it seemed like a fun little toy. Then, I did this (with alias git=git-achievements in my zshrc):

git <TAB>

aaaand, nothing. Just completion of files in the current directory. Where’d my ZSH git completion go?! Why didn’t it work across aliases?

My initial reaction was just to remove the git-achievements alias and use straight git. Then I decided to enter the Lair of the ZSH Completion Docs* and see if I could fix it. My first attempt was to edit my zshrc to add all the git completion functions to git-achievements:

alias git="git-achievements"
compdef git-achievements git-add git-am <...etc...> git-write-tree

Note that these were copied from /usr/share/zsh/4.3.9/functions/_git. That didn’t work. So I dove back in and found it:

compdef [ -an ] function names… [ -[pP] patterns… [ -N names… ] ]

…all the arguments may have the form `cmd=service‘. Here service should already have been defined by `cmd1=service‘ lines in #compdef files, as described above. The argument for cmd will be completed in the same way as service. [bolding mine]

Even that is hard to puzzle out, but it means that you can do this:

alias git="git-achievements"
compdef git-achievements=git

..and everything is fine and dandy.

*Note: I know that the ZSH documentation writers must be trying, and it’s mostly clear(ish), or at least comprehensive. But there’s so many options that it’s basically a hopeless task. I mean, I found this tip out on something like my 10th read of that page.

I Will Learn You A Crucial Bit Of Haskell: Comments

Learn You A Haskell For Great Good! is awesome (so far – I’m on the first chapter), but it’s missing crucial information: how to comment a line in a Haskell file. So here it is.

-- This is a single line comment
{- This is a multiline comment.
It can span more than one line. -}

Thanks to this page for the info. I wonder what a documentation comment is? Oh well, I’m sure I’ll find out.

Rails 3, Heroku, and Hassle

When I moved my Rails app to Rails 3 on Heroku, Sass broke. Or rather, Hassle, the plugin I was using to allow me to use Sass on Heroku’s system, stopped working, because it’s Rails 2 compatible, not Rails 3.

Thanks to this blog post, I found out how to fix it, and it’s quite easy. Assuming that you have the hassle plugin in #{Rails.root}/vendor/plugins/hassle, do this:

  1. Delete the hassle directory: #{Rails.root}/vendor/plugins/hassle
  2. In your Gemfile, add this line:
    gem 'hassle', :git => 'git://'
    This is a Rails 3 compatible fork of the original Hassle plugin.
  3. Run bundle install.

And you’re done. Hopefully, this will save someone else some hassle (sorry).