Vrapper is nice, Vim + eclipse

I like using vim, but all day I program in eclipse, which edits like a normal editor. The refactoring capabilities are important for my Java work. I tried eclim, but trying to learn the mappings is and get setup is just too much work, and some things are not yet implemented. I think with alot of time spent on it, it could end up useful, but for now Vrapper has been nice. I installed it as an eclipse plugin and it lets you easily turn it on and off. I also like that when you are normal mode it acts like a normal eclipse editor where highlighting works as expected, then you can switch back to vim mode with the escape key and do some more powerful editing, it doesn't do everything vim does, so sometimes it's better to use the real vim, but it does alot of what you want. For that I created an eclipse tool

Program:
/usr/local/bin/tmux

Arguments:
new-window "vim ${resource_loc}"

this lets me click my tool and open the current file I'm working on inside a new tmux window editing with vim. I typically use that when I need to do some substitutions because I like the way vim substitutes better than the modal dialog box eclipse uses.

Use Tmux instead of screen

I've been using tmux for awhile instead of screen. The options are a little more intuitive. The code is far cleaner than the screen code, and the development is active and ongoing. I've been working with Nicholas Marriot the maintainer to get a patch in (now added) to create some functionality similar to screen hardcopy and he has been very responsive.

better gnu screen copy mode

Ok, so I have been struggling with screen copy mode. But now, here it is, the ultimate screen copy mode.
Just make an alias out this:

alias a='screen -X hardcopy blah && vim -c "normal G" ~/blah'

or for tmux

alias a='tmux capture-pane;tmux save-buffer /tmp/screen_contents;vim -c "normal G" /tmp/screen_contents'

now type a<enter> for the ultimate screen copy mode. This gives you the full power of vim whenever you want to yank a couple lines from the text you already have on the screen.

git utilities workflow

One of my best workflow techniques it to use git cherry-pick to pull in what I call utility changes. A utility change would be like a change to point all the database configuration at the test database. Normally it's pointed at your local database. It takes a few minutes to make the change to the test database and sometimes you forget a spot. So to do it I first...

-- make the change to point at the test database --

# stash all your changes so you can checkout your utility branch
git stash

# checkout utility branch
git checkout utils

# put your changes back
git stash apply

# commit your changes to your utility branch
git commit -a -m "Point environment at the test database"

# switch back to the branch you were working on, trunk probably
git checkout trunk

# double check what branch you are on since you don't want to make a mistake
git branch

# find the commit sha number for those changes you just committed
git log utils

# cherry-pick just the change
git cherry-pick ab38b9

-- now you test your site against the test db --

-- you find out whatever you were looking for --

# get rid of the cherry picked commit from your branch and change back to pointing your database locally
git reset --hard HEAD^

your utility commit is still in your utils branch history so you can just git cherry-pick ab38b9 it out anytime you want and point at the test database.

Caps-lock escape

So I've been using vim for awhile now and finally changed my caps-lock to be my escape key instead of using Ctrl-[ which is just too painful a keystroke. I used was using that keyboard combination instead of the normal escape key because the normal escape key is way up in top left corner :0 Who ever would have put it up there? I guess the escape key used to be decently located on very old systems which is why it is being used for vim. Using the caps-lock key now I can change modes with one key, suitably located. Ahhhhh, that feels better.
Here's a link:
http://www.terminally-incoherent.com/blog/2007/08/02/remapping-the-caps-lock-key/

Git grep and navigate

I use Eclipse for my java project work. It has a decent search, but it is not all that fast, however what it does do is let you see what files have the search string and click on a list to get to a file of interest. I don't like using the mouse, but I need to be able to search for various strings and then view them in context to navigate the code.

Enter git grep. Git grep turns out to be a much faster alternative than even grep. What is nice about git grep is that it avoids searching through any non-git files (like the .git subdirectory). Also it is 10% faster than regular grep because if the way git compresses files. The uncompression and reading of the git files is actually faster than opening every file inode, so it can get that speedup. The problem with a simple grep is that after greping, typically you need to look at the context of the line. Grep has options for adding a few context lines, but I might need 10 lines of context for some specific lines and that can get hard to read. However, if I could use some curses interface to explore the files then it would be ok.

Enter vim. I found that Vim has a way of exploring a filename with a specified line number by typing gF (woohoo). So I tried

git grep -n "somesearchstring" > output.txt
vim output.txt

the -n on grep gives you the line numbers. I would rather have this as one-line command. So I tried

git grep -n "somesearchstring" | vim -

This bring up the grep list, but when you hit gF to go to a particular file vim wants you to save the file first, which is lame because these are just temporary files, I'm only using them for the moment.

So I wrote this alias for doing what I want

alias z="tee /tmp/blah; vim /tmp/blah"

This will save the output to a tmp file and open that tmp file.

So finally, my command is now


git grep -n "somesearchstring" | z

and up pops my vim editor where I can go to each file line of interest with gF and come back with ctrl-o. By the time Eclipse finishes it's search, I can already have found what I want on the command line, and no mousing.

Note: this can be further simplified by a bash function in your .bashrc

function gg { git grep -n '$1' | z; };

so that it becomes

gg "somesearchstring"

git svn switch

I have been using git as an svn frontend for awhile. Recently the svn repository was moved. At first I thought I would just change the remote repository in .git/config to point to the new repository. I did that, but when I ran git svn rebase I would get an error saying

"Unable to determine upstream SVN information from git-svn history"

I noticed that I could fetch, but I couldn't rebase. I found an answer here after awhile Googling: http://git.or.cz/gitwiki/GitSvnSwitch

Now I am able to use my git repo again :)

Making Kingston DataTraveller G2 bootable in linux

I bought a Kingston DataTraveller to transfer EasyPeasy onto my Asus EEE pc in place of it's Xandros operating system. After I downloaded the EasyPeasy iso and put it onto the usb stick with unetbootin I tried to boot into it from the AsusEEEpc but it would not boot from it. I ended up launching GParted. In that you can right click the usb drive and there is a dropdown that says "Manage Flags". I clicked that and clicked the checkbox next to the boot flag. After placing the iso on the drive again using unetbootin, it booted, and now I have ubuntu mobile on my EEEpc :)

Use Git to do your svn merges

I've been using git-svn as a frontend to svn. Git provides so much power that it makes it enjoyable to use source control. Despite the comment in the man pages of git-svn that says that it considered bad form to use git to do your svn merges, I have found it much more useful. The way I do my merges is that I just do

git checkout branchtomergeinto
git merge --squash branchtomergefrom

The --squash tells git to mash all the commits into one patch and not to commit, so that you can check it out first. This inevitably leads to some conflicts, so I then use

git mergetool

to go through and resolve all my conflicts using "meld". After you're all done fixing the conflicts and recompiling to make sure everything is good.

git commit

And type a message that will be appropriate in an svn context so maybe

git commit -m "Merging from funkycool branch r1500"

Then do your git svn dcommit. After doing a few merges out from trunk into a longer term project I was noticing that I was having to remerge alot of things I had formerly merged. This is because when you do a git svn dcommit git forgets about the tracking of the merges that you have done. I started hunting for a solution and found this article about using git grafts to restore svn merge history. Git grafts are awesome in that they let you declare what has been merged manually. By adding the git grafts for the merges you have done, the next time you merge out you will have far fewer conflicts. Git does it again.

j.sh easy directory navigation

A former colleague told me about j.sh which is a great little bash script that follows you around the directories you cd into and tracks how many commands were run in each directory. Then when you want to pull up the most used directory matching a certain pattern you just

j somedir

and then you end up in

/home/jon/deep/nested/somedir

and it will put you into that directory.

Much better than push, dirs combo.

Even better, you can add an additional param to qualify the first

j somedir qualifier

and then instead of

/home/jon/deep/nested/somedir

you end up in

/home/jon/deep/nested/qualifier/somedir

Super Simple Web Server

I needed to serve up some images on my computer from a different port. Mongoose is a super simple webserver. So creating a webserver to some static files is as simple as

mongoose -ports 9090

and you have webserver running on port 9090 serving up the content from whatever directory you're currently in.

Just go to

http://localhost:9090/

and there will be your content.

It can also run cgi bins and scripts so using a scripting language and some ajax libraries so you could build yourself some simple local apps in a pinch.