vimunit and gutter plugin updates.

I've been struggling my way through some plugin updates the last couple months, and I think...I think I'm about to a stopping place. For now anyway.

vimUnit

I took over the vimUnit plugin from Staale Flock a few years back and apart from a couple bugfixes I hadn't done much, until recently. I've made several updates to this plugin, the major new features/changes being:

• Its fail fast: previously assertions for this unit testing framework were a little wonky. Most unit testing libraries out there will 'fail fast': when a failed assertion is encountered in a test case, the whole test case stops. But the old implementation of this library did nothing of the kind; this leads to overly verbose and extraneous assertions.
• Stack traces: I did some low level vim hacking to introduce simple stack traces into failed tests. Now you have a good idea of the line number and underlying functions that cause a failed assertion.
• Command line tool: testing vim functions inside of vim can lead to many possible IMO dirty editing environments. The command line tool ensures that when you run tests you don't mess up your current editor, and your tests always execute in a clean vim environment.
• Shiny new website: http://dsummersl.github.com/vimunit/

Sluice

Several years back I wrote a gutter plugin that would automatically show you all matches for the current word under your cursor and any searches you may have performed. Well, I've done a pretty complete rewrite to support graphical icons as well as git modifications in the gutter. Still working out documentation and such, but definitely worth checking out. I'd love some feedback.

Conditionally applying macro recordings.

I make and use recordings in Vim all the time. I cannot imagine my daily work-a-day life without them. The most common reason for using recordings is to perform a complex modification of a semi-formatted dataset: SQL result sets, CSV, TSV, XML, HTML, etc...

As with most things in Vim when you find some new way feature, you find that you probably already had the parts laying before you, but hadn't quite had the 'manual' to put all the parts together. Recently I found a new way to do so conditionally, that I thought I'd share; its one of those methods that has probably been staring me in the face for-ever, and I just didn't see it.

So. What am I talking about? Conditional Macros. Lets break it down:

Macros

Plain and simple. Here is a simple problem that I think requires a macro. Suppose you have some lines of text like the following:

List A: 108 unique colors, 387 total colors

List B: 266 unique colors, 1343 total colors

List C: 361 unique colors, 2554 total colors

List D: 174 unique colors, 1221 total colors

List E: 301 unique colors, 2665 total colors

Suppose you wanted to compute the difference between the total colors and unique colors. So, in the case of the first line this would be 387 minus 108. You can do this once, sure. But suppose there are a couple thousand lines, and you want it all done, and done in Vim. No problem. You would record a macro like so:

1. start your macro recording to register m (qm)
2. go to the beginning of the line (^)
3. move up to the first number (WW)
4. store the first number in a register ("iyw)
5. go to the second number (f, )
6. store the second number in a register("oyw)
7. compute the difference between the numbers (:let @s=@o-@i[carriage return])
8. print out the result at the end of the line ($a == [control r]s[control c])
9. move to the next line (j)
10. stop recording (q)

If you were to examine register m, you would see:

^WW"iywf, "oyw:let @s=@o-@i[carriage return]$a == [control r]s[control c]j

And if you executed this macro (@m) for each line you would get something like this:

List A: 108 unique colors, 387 total colors == 279

List B: 266 unique colors, 1343 total colors == 1077

List C: 361 unique colors, 2554 total colors == 2193

List D: 174 unique colors, 1221 total colors == 1047

List E: 301 unique colors, 2665 total colors == 2364

To do several lines you would replay the macro by typing something like 5@m to do it five times, etc.

Conditional

When conditional modification pops to mind, I think of the global command (:g//). Whenever there is a match for the global command, it executes some arbitrary commds. So suppose you had text like the following:

...

...

Uninteresting line

List A: 108 unique colors, 387 total colors

Uninteresting line

Uninteresting line

List B: 266 unique colors, 1343 total colors

Uninteresting line

List C: 361 unique colors, 2554 total colors

Uninteresting line

Uninteresting line

...

...

You could just delete all the uninteresting lines like so:

:g/^Uninteresting line$/delete

Conditional Macros

Now, you could just delete everything not interesting and then run your macro on whatever is left. But a lot of times, you might find that you are interested in 'fixing' some lines but leaving the rest of the text unchanged. You can do this by combining the global command with a macro. So suppose you had:

...

...

Mildly interesting line

List A: 108 unique colors, 387 total colors

Mildly interesting line

Mildly interesting line

List B: 266 unique colors, 1343 total colors

...

...

To execute the macro you created, but only for the interesting lines you can combine the macro with the global command:

:g/^List/norm @m

Which would yield the desired result:

...

...

Mildly interesting line

List A: 108 unique colors, 387 total colors == 279

Mildly interesting line

Mildly interesting line

List B: 266 unique colors, 1343 total colors == 1077

...

...

New indenthl syntax plugin

I've still been getting comments on my original indenthl post, lo four or so years ago. Back when I wrote it I was an advocate of the 'set noet' (no expanded tabs - a tab means a tab!) form of consistency. Although I still prefer this method for its individual control (I like 2 char tabs, you like 4 char tabs, some fool likes 8 char tabs) I've noticed at my job people mix spaces and tabs (no we're not a python house, although we were a jython house for a while). The result: UGLY. Anyway, I'm beginning to see some of the virtues of a 'set et' world.

Thus saying, I've done some IndentHL syntax updates. It now has a couple new features (and settings!):

• Error highlighting: if you have a line indented with a combination of tabs and spaces then this will highlight it as an error.
• 'follow the expandtab' setting: If you turn off the expandtab setting then the syntax plugin will highlight anything that isn't TAB'd out as error prone. If you specify et then the syntax plugin will do its same 'indent level highlighting' it did before for spaces (using your shiftwidth setting), and it'll highlight in red anything thats tabbed.
• A setting to turn off error highlighting: maybe you don't care about consistency. Well, you can turn it off.
• I originally designed three different highlight modes (see my original post). You can now pick which one you want (as a setting).

Also, I moved this syntax project over to github. Of course, its over at vim.org as well.

Trying a new configuration scheme

So the other day I noticed this *amazing* plugin for looking at VIM's undo history. The guy says, if you aren't on pathogen get on it.

Round 1

pathogen is a simple Vim script that lets you put each plugin into one specific folder all on its own. Its own sandbox. I like this idea because as a user of many many plugins, debugging them can be troublesome: which files are related to the plugins, how, is it documented, etc. Its hard when every single plugin is dumped into your ~/.vim folder. Now each plugin is dumped into ~/.vim/bundle/.

I made a new .vim folder, and put pathogen in. Tried sticking in each plugin. What a pain, all this manual folder creation. Very very cumbersome. In fact, in the first round I couldn't get most of my plugins to even work. Everybody was complaining.

I gave up, went back to my old .vim folder.

Round 2

Looked around the internet a little more and found this blog entry at Tammeh Saleh which offered a solution: instead of manually porting all your plugins over, use a script (update_bundles.rb) to setup all of your github and vim.org scripts.

Genius, of course!

Tried the script out. Seemed like it might work out. Folders magically appeared in my ~/.vim/bundle folder. But. A lot of things still didn't work.

Upon investigation I realized that a good deal of the vim.org scripts I use are zipped, or tar.bz2'd or targ.gz, or vba.gz'd up. As wonderful as the ruby script was, it assumed that all vim.org scripts are zipped. Wrong.

I gave up, and stewed.

Round 3

Fine. I'll mod the script. Now I can totally blow away my ~/.vim/bundle folder and run this little ruby script and it completely regenerates regardless of zip/bzip/vimball/etc

Requires some slight manual intervention for vimball installation (it launches vim, runs the vimball install, you just have to :quit out after to get it on its way).

I think I'm happy.

Switching to pathogen also had another slight improvement. Some of my own personal duct tape type plugins got themselves checked into github for the first time. Probably should have done that awhile ago.

If you wanna try this out yourself I suggest you download my script, and read the Tammeh Saleh blog entry.

multiline matching

Similar to my previous post on adjacent nontrivial searches, I've recently had to do something similar except that I need to find things that are the same on adjacent lines.

For instance given the following:

1003065,PARKBT,99.00,0.00,0.00,,2009,1089.00
1003133,PARKBT,210.00,0.00,0.00,,2009,1470.00
1003234,PARKBT,180.00,0.00,0.00,,2009,1980.00
1003316,PARKAT,45.00,0.00,0.00,,2009,45.00
1003316,PARKBT,230.00,0.00,0.00,,2009,2705.00
1003360,PARKBT,210.00,0.00,0.00,,2009,1260.00
1003377,PARKBT,110.00,0.00,0.00,,2009,1210.00
1003404,PARKBT,180.00,0.00,0.00,,2009,1980.00


In this case I'm interested in finding matches where the number at the beginning is repeated in a couple more than once (the lines starting with 1003316). This is the resulting search: /^\v(\d+),.*$\_.^\1,

The trick here is to use the \_. to match the end of line, and then match zero width beginning of line.

Still no column level folding in VIM.

I used to think that VIM was right there on the 'cutting edge' of new editing concepts. I remember encountering Origami (the original project is dead I guess, can't find a good link) while I was in college. It have this novel idea of 'folding' lines so that you could hide large sections of a file. I thought, interesting. Not long after that feature was incorporated into VIM (no I'm not going to look up version numbers and embarrass/age myself!). A few years ago I had heard that someone had written a patch for VIM that enabled horizontal folding to offer similar advantages to the line level folding: simplification. I didn't think much of it, but stashed it away...confidant that *someday* it'd be part of VIM (if it were useful).

Well. Its been several years, and I just realized that Intelli has incorporated it into their own editor, and it is useful. Screenshot:


See the little <->? That's folding along the horizontal line. If you have the 'vi' plugin in Intellij it even acts like a fold: type 'zo' to open it. You get a lot longer string (sorry I'd type it out but blogger's editor doesn't like <> in that particular combination). I couldn't say I saw a use for horizontal folding before...but I do now! So much more readable with folding. I want it in VIM!

Note: I've been using the AnsiEsc.vim plugin for a little while, and I didn't even realize that it'd been specifically written to take advantage of Vince Negri's patch. Shame on me. One more reason to compile MacVim.

Macro Search take three (err, update)

Okay! So I've been hard at work on some new features. Make sure you've seen the first screencast - then get a video overview of the new 'under the cursor autosearch' feature by watching the changelog screencast I made:


But. I also left some features out. A mostly complete list of the new features:

• A new 'under the cursor autosearch' feature. In short: you are shown all 'iskeyword' words in the file that match whatever 'word' is currently under your cursor.
• Limited searches: the search and under cursor search plugins are limited to 100 matches so as not to kill you on larger files (searching for redundant things that match everywhere).
• Colors! In GUI mode the intensity of the // and \\ colors will go UP when there are lots of matches in that region of the file. Dull == 1 match, brighter == more matches.
• console coloring: the console doesn't support this level of granularity so I've given it a basic 8 color black/white/brown so that you get all the same basic functionality (minus the intensity telling you the # of matches).
• hopefully more stable? Hopefully more complainy if you don't have +float or +signs support? One hopes :)

A screenshot of the plugin in console vim (uhh, this screenshot doesn't make *any* sense unles you've watched the screencasts so...get to it!):


If you're interested try it out - just drop it in git repository. I'd be interested in some feedback before I tack a version on it and stick it on vim.org's plugin site.

Macro Search take two

Thats right I've reworked the idea I had earlier for a macro level search in VIM ala the IntelliJ features I had mentioned.



At any rate - I'm adding another feature or two as I go along which I'll surely blog about. Its buggy, but it mostly works and isn't butt ugly.

You can try it yourself by downloading it from its git repository.

Some recent nontrivial searches

Doing a lot of CSV file analysis the last couple weeks. Some things I've needed to do:

• [^X]: Find out if there are any fields that don't match the typical pattern. Here's one. In this file I noticed that most files 2nd field had the pattern of four numbers followed by the letter A. I wanted to see if there were any that had some other character at the end. When I used s/\d\{4}[^A], lo and behold there was indeed a nonstandard entry:

102,0949,0277A,1,0.00,"

102,0282,0282A,1,0.00,"

102,0284,0284B,1,0.00,"

102,0287,0287A,1,0.00,"

102,0288,0287A,1,0.00,"

102,0289,0289A,1,0.00,"

• \1: Then I noticed that in a lot of entries there were field 2 and field 3 pretty much matched in most cases. I wanted to see which ones didn't match. At first it was easier to look for the matching entries with the following s/\v(\d{4}),\1\u,:

102,0949,0277A,1,0.00,"

102,0282,0282A,1,0.00,"

102,0284,0284B,1,0.00,"

102,0287,0287A,1,0.00,"

102,0288,0287A,1,0.00,"

102,0289,0289A,1,0.00,"

• \@!: Its actually a little confusing, but it can be done. By using the zero width matcher \@! you can specify that it NOT match the previous but then you have to fill in some for the part that it will match. Strangely the \@! matcher doesn't respect the \v 'verymagic' setting, so you end up with a lot of slashes in the end result. And this is what it looks like \(\d\{4}\),\(\1\)\@!\d\{4}\u,:

102,0949,0277A,1,0.00,"

102,0282,0282A,1,0.00,"

102,0284,0284B,1,0.00,"

102,0287,0287A,1,0.00,"

102,0288,0287A,1,0.00,"

102,0289,0289A,1,0.00,"

quick * and # search hack

A friend of mine introduced me to a quick way to use the * and # commands (which let you quickly jump to the next or previous instance of the 'word' under your cursor). Generally a word is ([A-z][0-9])+. When you use the :set lisp option though, it then includes the '-' character as well. An old school option that makes for a nice quick hack.

There is however a general solution: it turns out there is yet another thing I didn't know. You can change what a 'word' is in vim by modifying the 'iskeyword' setting.

To see what characters are considered to be part of a word you can type:

:set isk

iskeyword=@,48-57,_,192-255

I've found that its pretty easy to change things up when you need a slightly different usage from */#. For instance, if you are searching some keywords of the form:

final int TRANSIENT-RAT-SCH-CODE = -1;

Suppose your cursor is on the 'T'. If you hit * or # you would be brought to the next or previous instance of 'TRANSIENT' because '-' isn't in the 'iskeyword' setting. Quick fix? Do:

:set isk+=-

Then it'll match the whole big bad thing.

entire file view of matching searches.

So I've been using IntelliJ a lot for my Java and groovy development lately and noticed a cool feature of its editor recently. When you do a search, a little tick mark is made along the area of the scroll bar for each match to your search. This is kinda cool as it gives you a general idea of how many matches there are in the file, and a general sense of where they are.

So I was thinking. I wanna do this in Vim. How? Well, if you have +signs support built in...you could do as I did. This is what I got toward:


This works in the same general way: the green hilighted area essentially corresponds to the scrollbar...it shows you what part of the whole file you are looking at right now. The little ticks show you where the other matches are in your file.

Anyway, I think its generally a cool idea. I've made a plugin that shows this stuff on the side whenever you have the 'hls' setting on. Whenever you move around the file it automatically updates so its generally correct. Still some bugs, but I'm working on it. You can try it out yourself from github.

General conclusions/thoughts:

• vim-unit continues to rock. I'm almost to the point of considering going all ruby or all python for serious vim scripting though.
• It sure would be nice if there were events you could subscribe to when your location changed in Vim. There is something for window sizes changing...but w/o this you're pretty much stuck using the CursorHold type cludges - which just feel like cludges unless you get your handler code really efficient (quit early, do as little as possible, set udpatetime high).
• I wish MacVim supported images for +signs! I've checked out the MacVim project from git. If I get some free holiday time I'll definitely look into making images to get a more IntelliJ like result -- although I suppose the solution I have now is good in that it'd work on the console. Still.
• Wouldn't it be sweet if you could have a left gutter +signs support as well as right gutter? IntelliJ really can tell you a lot by making use of them.
• I'm thinking this +signs thing for code coverage tools would be kinda nice...have to look into that at some point...

NetRW and MacVim

So since I upgraded to snow leopard I could have sworn that the netrw just stopped working. Every time I tried:

:e scp://somhost/somepath/file.txt

I would get some gobbly gook about not knowing how to handle a BufEnter event or some such thing with regard to "scp://".

I'm using Snapshot 50 since that works better than the last stable build (I recall some repainting issues). Well, it looks like maybe the snapshot doesn't include the netrw plugin. So I just downloaded it and installed it manually and all is good with the world, yeah!

:e ~/Downloads/netrw.vba.gz
:so %

YouTRACK: a bug tracker for the vim-ish?

I got an email yesterday from jetbrains, notifying me that their internal bugtracker YouTRACK has gone beta. "Try it out!", they tell me. Okay, I like jetbrains stuff, so I bit. I'm posting here about it because it kind of reminds me of my learning process with VIM. Back when I first started using VIM I remember that I suffered through the initial arcana: I couldn't do anything at first (it was hard), then I began to cotton on to the general concept (but I couldn't really do it), at last I could do things fast, and finally I wondered why it didn't have all those kitchen sink features other products have. Doesn't this sound sooo reminicent of using VIM?

If you have ever used VIM you probably remember struggling just to frickin...TYPE. Type anything at all. And then once you could actually do that, well - what about saving and exiting? Escape? :wq? Ahh...those first few baby steps. YouTrack totally hit me like that. Of course they provide GUI menus for everything but me being a VIMish user, I wasn't interested in the easy/slow way. I had to figure out how to do everything by hot-key only. After all, the speed what supposedly sets this bugtracker apart. The installation part was easy. Download the WAR, stick it in tomcat, and fire it up. Bam. Its up and running. Copy and paste the demo license from their website and I'm good to go until December 2nd (after which point I'll have to buy a commercial license if I actually like the thing? How much?? Who knows...we'll see).

I setup a couple small projects I'm currently working on (too small for a bug tracker - or rather, too small to be worth the trouble). First impression: interesting. There is a search window with type-ahead keywords that appear as you go. How do I make a new bug? Ah. A hotkey (and by mouse of course, but I'm ignoring that as I said).

I easily entered a couple bugs and a couple projects in the system. I'm working on a project and I want to pull up all the bugs, how do I do that? It takes me a couple minutes stumbling around with the search window to figure out what the syntax is "project: AA" - ahh...tab completion. Nice. So there were are - a couple bugs. How do I get from searching to modifying bugs? Durn durn durn I stumble on this for 20 minutes.

Ahah! ESCAPE! Of course. Wouldn't you know it would be the same key that is such a stumbling block in VIM too. Go figure. Once I figure that out, oh my god. Its the frickin easiest thing to add comments and tag bugs. A breeze. Very snappy. I'm loving that. I can now see myself setting up projects and adding bugs for trivial little projects in no time. Nice. Perhaps even todo lists in general. Quick modification of tab names, batch updates, etc. Power.

Of course, now that I'm enlightened, I have questions. Lots of questions. Kitchen sink type questions. Can I use external java/javascript to make mashups (say burn down charts, remotely add bugs say via my own applications, etc). Whats the best practice for agile delevelopment say? Integrate with other back end bug trackers like bugzilla or trac? As I keep playing with it over the next few weeks I'm sure I'll have more questions and comments. But so far I like it a lot. Just wish I knew what I'm gonna have to pay for the thing once they go commercial with it a few months down the road (ie, once I'm totally addicted).

Daniel in Nowhere: Put Searched results into a split window under VIM

Hey this looks pretty cool - every now and then I've wanted to see search results in a nice searchable list. Gonna have to try this plugin out:

Daniel in Nowhere: Put Searched results into a split window under VIM

Registers

There is always something new to discover out there, particularly with Vim. I thought I knew how registers worked: you got your window manager registers (+ and *); the 'last thing I deleted' register ("); the confusing 'last 10 deletes' registers (0-9); some read only registers that I don't consider to be registers because, hey, you can't write to them (% and #); and then the multipurpose named registers (a-z).

I've programmed myself over the years to use specific letters for specific purposes. The 'n' and 'm' registers are reserved for recorded macros (yes, macros are saved in registers - handy to know if you want to save a macro in your .vimrc for later use, say), the 'iou' I tend to use for registers that are used in a macro, and 'fvc' for yanking and storing.

For instance, if the lines below existed, and I wanted to copy the first one for later use:

every good boy
does good

I'd do: "fyy

Now, if you type ":registers" you can see all of your registers, and thats overwhelming. I tend to just look at the register I'm especially intersted in ":echo @f" or ":registers f" does the trick nicely. Also, since I know I use the 'fvc' registers for yanking - I tend to just look in those registers if I forget what I've done with ":reg fvc".

Did you know that you can append to the named registers? I had NO IDEA. By using the capital letter 'F' instead of the lowercase letter 'f', for instance, you append rather than replace. Take the example above. Say that I was going along editing and I saw another line I might want to use later:

...
...
blown up beneath my glass.
Colors dazzle insect wings.
...
...

I could, if I wanted, just add it to register 'f' with the other line by doing: "Fyy

Type ":reg f" and you see:

--- Registers ---
"f Every good boy^JColors dazzle insect wings.^J


Not too pretty, but thats where this comes in handy: ":echo @f"

Every good boy
Colors dazzle insect wings

Press ENTER or type command to continue

There you are - a case for using 'echo' over 'register' and an interesting note about the named registers.

Another one trying to come back to vim. I sense a theme.

Just saw this post today, about another person trying out switching from TextMate back to their first love: VIM. He switched back to TextMate, and I can understand his reasons. Plugins in Vim do tend to feel 'bolted on', and they can be kinda slow. Although you can certainly customize Vim so that it fits your work requirements, many times I think we all have to customize it for our own needs because, out of the box, its not doing what we need.

This makes me think of cream, a distribution of Vim customized for non-Vim users, in the mode of word processing.

We need some other distribution out there that tightly integrates some of the really amazing plugins that are out there. A cream-for-programmers who know the power of TextMate, IntelliJ, etc.

One thing that might make also go into this soup...has anyone out there noticed the 'netbeans' extension to vim? I've seen the switch and read about what it was supposed to do - tightly integrate Vim on top of netbeans...so you can harness the power of netbeans inside Vim. Fancy icons in the gutters, cool refactoring features of netbeans in Vim. I'm only guessing here, but thats what I *think* the netbeans integration was supposed to have provided. There are certain automagical properties of the big battleship IDEs that Vim just isn't meant to provide...but perhaps providing a way to interface with them would bring those 'other IDE' users back into the fold.

Eh...I don't know. Personally, a kickass tightly integrated distribution of vim with existing plugins would make me happy ... the IDE integration really seems like overkill. But...who knows.

file lookups

I've been hearing about this post from a TextMate guy (I'll call him TM1) finally coming home to Vim(hey, if you're gonna link to some other random editor, you GOTTA plug your own!). Good good. In fact, from any command line editor's point of view: amazing. Its funny though because THIS TextMate guy (call him TM2) got me to write up a plugin very similar to TM1s.

Before I go any further - just click on the 'this post' link above and watch the short movie the guy recorded. I'm lazy, I'm not going to make a video. Once you've watched the video you'll understand what we're talking about: an gosh-its-almost-like-its-an-IDE friendly way of finding files in your project.

Its the kind of thing that just has to be there for any programmer under 35 - we're just not going to fall in love with the :find and :grep and :vimgrep commands of the previous generation. Its just not easy enough. For some people the project plugin does the job. I admit, I kinda like it myself...but I always missed the easy file lookups you get in Eclipse, IntelliJ, etc etc etc. Being a Java guy mainly, I really love how easy Intellij makes it.

When TM2 expressed interested in making the final journey from emacs->textmate->vim, you better believe I was there to encourage him. When he complained that there just wasn't any good Command-T equivelant in Vim, you bet I looked around. I found the lookupfile plugin. At the time this was version 1.4 of the plugin - it was slow, it didn't do camel case searches (fuzzy finder doesn't do that either !?), you couldn't search inside files (ala grep).

I extended the plugin with my own version and tried to get TM2 to use it. Unfortunately my skillz aren't quite what they could be in vimscript. However I was able to get the following working (and hey, it still works!):

• I implemented searching using the standard unixy textutils and findutils packages underneath (find, sed, grep, xargs, etc). The first search is still slow b/c it builds up the search terms, but then they stay cached...so subsequent searches are blindingly fast.
  
• Compatibility with &path and &suffixesadd settings (the variables used by :find, :grep, etc). Basically you can setup &path/&suffixesadd and use :find, :grep, and your friendly lookupfile functions all interoperably. I setup mappings where I only searched say...java files; or java, xml and properties files; or ruby and xml and yaml. Complete control over which directories you search under, as well as their extensions.
• Support for case sensitive or non case sensitivity.
  
• Camel Case search. Not only can you do 'c*frog' to find 'CamelFrogMasterFactory.java' (or with case sensitivity 'C*Fro'), but you can do 'CFro' as well (a * is implied after each capital letter).
• Grep search: same way of searching (nice filtering list) but search the file contents as well. If it worked better, I'd maybe win that $100 bounty :).

But I had a problem - those darned findutils and textutils I built everything on aren't standard on OSX and so my TM2 friend had no end of trouble. It just was buggy. I guess it still is, but...

since somone else has published their version, and I found it hella slow, I figure...hell, here's my effort as well. Maybe someone out there would like to pick up where I left off.

You can find the result of my efforts right over here. Now.To work.

MacVIM and cd

Just a quick note. For you Mac & Vim users out there - MACVIM. It truly rocks.

Also, a quick "oh my gosh I'm so glad I finally found a command for this," and then a "doh, of course!"

I often launch Vim and then have to work on a set of files in some specific project directly. Its a pain to have to type something like:

:e ~/Documents/ProjectA/subProjectX/file1.py
:sp ~/Documents/ProjectA/subProjectX/file2.py
:sp ~/Documents/ProjectA/subProjectX/file3.py

over and over and over again. I've been looking for the command to set your 'current directory', and I found it: cd. Duh:

:cd ~/Documents/ProjectA/subProjectX
:e file1.py
:sp file2.py
:sp file3.py

So much better.

javascript vi clone

Thats right, check this out. VI implemented in javascript.

Review of "100 Vim Commands every programmer should know"

This morning I woke to find that a number of blogs out there there have picked up an article called "100 Vim commands every programmer should know" over at CatsWhoCode.com. Of course, I had to go over there and scan down the list to see if there was something there that I might need to know.

Search

Commands under the 'Search' category are simple enough: straightforward word boundaries and regular expressions mixed in.

Replace

The 'Replace' category is much the same. Ranges are covered extensively. Unfortunately, I think it got a bit too general. The 'global' command was mixed in here, and only glossed over with the following paltry commands:

:g/string/d Delete all lines containing “string”
:v/string/d Delete all lines containing which didn’t contain “string”

Interestingly I'd never heard of the ':v' command, but now I know why...its equivalent to the ':g!' command.

An oldy but goody was included in the 'Replace' category as well, to with XML tags:

:%s#<[^>]\+>##g Delete HTML tags but keeps text

At the bottom of this section I saw "Change text to Rot13." Rot13?? Ah. To be honest I haven't in my paltry 14 years on the internet ever found myself using Rot13 for anything, so I have to say I'm a little surprise this makes it into the "Top 100". Onward.

Case

Amazing! I have a big black hole in my head when it comes to case commands. Oh no, nevermind. Funny how it is that you sometimes actually have to use the command sequences before you realize, oh...yeah, I know that. Duh. To deal with words I prefer the 'inner word' type commands. Rather than doing 'vE' to select a word as is done a couple times here, I would do 'viw'. I think you would find 'viw' more forgiving than 'vE' if you were whipping up a recording, say, as it'll actually select the whole word. 'vE' only selects the current position to the end of the word. Minor detail I suppose. I didn't know about this setting though. Sweet:

:set smartcase Ignore case in searches excepted if an uppercase letter is used

There were also a number of case replacements using sequences like:

:%s/\<./\u&/g Sets first letter of each word to uppercase

I'd tend to categorize this as 'Replace', but thats just me. Also, I don't often use the these generic sub replace commands in favor of the generic sub replace method. I'd do this more generic replace:

:%s/\<./\=toupper(submatch(0))/g

Hmm, yes. I should learn to use those other matches. Mines a bit verbose.

Okay, so I've only reviewed about 1/3'rd of the entire list. On the whole I think its a good list, though the categorization is a bit loose. There were a few good comments on the article (and the author acknowledged them as well; they should get a pat on the back for listening to the readers). Worst offense: leaving out recording macros. Definitely should have been in the top 100.