VIM-ing

Conditionally applying macro recordings.

2011-07-01T12:00:00.000-07:00

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:

start your macro recording to register m (qm)
go to the beginning of the line (^)
move up to the first number (WW)
store the first number in a register ("iyw)
go to the second number (f, )
store the second number in a register("oyw)
compute the difference between the numbers (:let @s=@o-@i[carriage return])
print out the result at the end of the line ($a == [control r]s[control c])
move to the next line (j)
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

List B: 266 unique colors, 1343 total colors

Uninteresting line

List C: 361 unique colors, 2554 total colors

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

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

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

...

New indenthl syntax plugin

2011-03-23T09:41:00.000-07:00

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

2010-11-10T07:30:00.000-08:00

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

2010-03-02T12:50:00.000-08:00

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.

2010-01-27T12:14:00.001-08:00

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)

2010-01-20T21:08:00.000-08:00

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

2010-01-13T12:00:00.000-08:00

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

2010-01-12T08:12:00.000-08:00

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

2010-01-07T06:32:00.000-08:00

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.

2009-12-20T21:38:00.000-08:00

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

2009-11-19T11:36:00.000-08:00

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?

2009-09-04T08:03:00.000-07:00

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

2009-03-04T09:17:00.000-08:00

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

2008-12-09T07:34:00.000-08:00

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.

2008-11-07T06:46:00.000-08:00

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

2008-10-24T07:33:00.000-07:00

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

2008-07-10T07:04:00.001-07:00

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

2008-07-07T10:16:00.001-07:00

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

Review of "100 Vim Commands every programmer should know"

2008-07-01T05:58:00.000-07:00

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.

dip and vip it.

2007-06-27T09:00:00.000-07:00

Thats right, paragraph manipulation is as easy as three keys. I tend to just use 'dip' and 'vip', but there have gotta be other good ones out there...

yip? yep.

grip? Rip? darn! No, that doesn't work. Changes you back into insert mode.

cip? okay, yes.

g?ip? Yes, kinda silly though.

>ip? yes.

'ip' is just inner paragraph. You could do various kinds of inner blocks and quotes.

Convenient tab commands

2007-05-23T10:35:00.000-07:00

I was conversing with a friend about how to turn a split into a new tab, and vice versa this morning. You can call IMing 'conversing', right? Yes. At this day and age, I'd hope so. Anyway. We came up with a couple convenient commands/abbreviations. Take your pick:

" Close a split and then open it in a new tab:
:ca tb let a=bufnr("%") q tabnew exe "b ". a
:command! Tb :let a=bufnr("%") | q | tabnew | exe "b ". a

" Close the current tab and open as a split in another existing tab:
:command! Ts :let a=bufnr("%") | tabprev | sp | exe "b ". a | tabnext | q | tabprev
:ca ts :let a=bufnr("%") tabprev sp exe "b ". a tabnext q tabprev

Note these obviously aren't that smart. If you have no splits, its not gonna act quite right. I've made the order open X, then close Y so that vim still has *something* open. Hopefully that means your Vim session won't disappear out from underneath you.

Yep, I just tested it out. Vim doesn't close, and the 'tb' command works fine regardless of the # of windows open. The 'ts' command acts a little funny when there is more than one split open in a tab. It removes one split, sticks it in another tab but doesn't completely remove the other tab b/c there's still a window in it. Not so bad. Just a little wierd.

Recursive Diffs?

2007-05-21T12:34:00.000-07:00

It appears that, yes, someone has already gone out and written a plugin for recursive diffing two folders. According to one person, it works relatively well. What I'm wondering is, could this plugin be used to diff two revisions in say, SVN?

Well, I had a chance to try the thing out and I have to say that I am happier doing:

:r ! diff -r --brief

and then making my own quick macro to diff any files mentioned in the diff results. I just like the ability to filter out any lines I already know aren't a factor in my diffing. The DirDiff plugin doesn't allow you to change the contents of the 'diff results'. Well, I was at first. Until I figured out all I had to do was type:

:set modifiable

Then I could delete the 'results' screen willy nilly. Much better. It still complained if I tried to insert text or what not...so its kind of a toss up. If I needed to quickly copy the contents back and forth then this DirDiff tool would be just the thing.

The trouble is most of the time I'm actually looking for a needle in the haystack. Some little change in a text file is causing a world of havoc for me. I don't want to filter out 'types' of files, and copy whole swathes of differences between the trees. In this case, I think manually reading in the diff and recording your own little quick diff macro is the way to go. DirDiff is slightly too constrained in what it wants to let you do.

In summary: a good plugin if you need to copy back and forth changes, or you don't want to spend the extra 3 minutes it takes to record your own diffing macro. I've rated this script 'Helpful'.

Quickly delete several random lines

2007-05-15T14:50:00.000-07:00

I just couldn't think of a quick way to take a subset of a file, where some # of lines had been randomly deleted. Since VIM doesn't have its own random() command you have to turn to some external method of determining which lines to delete. My solution was ruby:

:ruby VIM.command(String(rand(VIM::Buffer.current.count-1)+1) +"|d")

To repeat the command several times I couldn't think of anything better than a macro recording:

:let @l=':ruby VIM.command(String(rand(VIM::Buffer.current.count-1)+1) +"|d")^M'

Where '^M' is really Control-J cariage return. Then to do it...uh, 30,000 times I just typed 30000@l

Indent level highlighting

2007-02-17T12:54:00.000-08:00

I have finally begun to delve into the world of VIM syntax highlighting. The syntax used by VIM that give all my different files such pretty colors have always been something of a mystery to me. Recently a problem caused me to make the jump into the :help syntax pages.

There was on my part some assumption that someone had already done what I wanted to do, which is to highlight each successive indent level in a file. This would be particularly helpful for python files, but other programming languages as well. The BlockHL looked like just what I was looking for. Interesting, and helpful, but not quite.

Delving into the documentation I eventually found after much scratching of the head how to do exactly what I wanted to. Piddling around with the highlight colors I came up with three variations. I think I like the right most one best.


BlockHL syntax plugin	Progressively darker indenting, kinda loud.

Alternate coloring. Better.	Alternate color, with progressively darker shading. Best.

I've posted the very simple coloring script on vim, as a script plugin. See its page for further details.

*** update ***

Well well well, apparently some poeple actually read my postings sometimes and call me out on my shoddy programming skillz. Yes, its true. This plugin only works with TABs. Maybe if I get less lazy, I'll make it work with the tabstop/shiftwidth settings for you non tab users.

switching between bash and batch scripts.

2007-02-06T07:45:00.000-08:00

Were it only as easy as s/sh/tch/! Well, it almost is.

For the most part only a few search replaces are required. Most of the tme I need to convert a dos batch to a bash script. The first round of conversion includes:

:set ft=unix
:%s/%$\w\+$%/$\1/g
:%s/set //ig
:%s/rem/#/ig
:%s/;/:/g
:%s/\\/\//g

There is always additional work to do, but these replaces do most of the tedious portion for me.

Multi Line searches

2007-01-11T07:47:00.001-08:00

I often forget about the "newer" searching features in VIM's regular expression quiver: line aware regular expressions. Today, I needed to detect when certain requests had occured twice in a row without any response in between.

First, I grepped the patterns important:

grep "REQ\|RSP" file.txt | vim -

Then I searched for two REQ's in a row:

/REQ.*\_..*REQ

Tada! Wow, that was just so easy.

I haven't played with these kinds of regexps enough to know if you can extend it to say three lines in a row or say two lines with the pattern, and one without, etc. But, I expect it is quite possible with a little work.

Freezing titles ala spreadsheet land.

2007-01-08T01:51:00.000-08:00

Every now and then I have to read the results of a SQL query on the command line, and I find the following setup to work wonders in VIM. At least this works well with MySQL, as its command line query tool is kind enough to spit out the output in tab-delineated form.

Say you have a query to perform. Do the following:

echo "select * from tableX;" | mysql -uUser -pPassword databaseName | vim +'set scb sbo+=hor sbo-=ver nowrap ts=30 bt=nofile| sp | exe "norm \<c-w>j\<c-w>_\<c-e>"' -

This will automatically space out the tabs so you can see each of the search result columns with the data, and then it creates two panes - one for the column descriptions, and one for the data. The scroll options are setup so that you can navigate around the data and always see the column description with the data (particularly helpful for large result sets).

The only real improvement I can think of is to use the VIM dbext plugin. I often find myself on several different machines I don't use often enough to warrant customizing plugins/settings, so this quick and dirty sql result browser setting is very handy to have around.

Automatic formatting.

2007-01-05T09:32:00.000-08:00

For me it is rare that I use VIM to compose text messages. This is unfortunately due to the nature of writing in VIM: it isn't embedded in the browser window where I am currently composing this blog entry, and it isn't in my mail composer (unless I'm using mutt). Its just not the de facto standard for editing no matter how much I sometimes which is was.

Nevertheless, sometimes I do want to compose a message in VIM. When I do, its usually so that I can take advantage of the automatic formatting features in VIM. Here are the typical settings I use to setup a text editing session:

:set tw=80
:set fo=at

This gets me just the basics: when I insert/delete text in VIM, the text is automatically wrapped/unwrapped.

But I really want my numbered lists to be formatted correctly. In that case I add on an extra flag:

:set tw=80
:set ai
:set fo=atn

Of course, in VIM 7 you can add spell check to that:

:set spelllang=en_us
:set spell

Use the the z= command to find alternate spellings underneath your cursor.

Capitalizing Sentences

2006-11-23T18:25:00.000-08:00

Here is a quick way to search for some letters, and then capitalize them quickly. I wanted to capitalize all of the letters at that start a line. Here was my query:

:%s/^$\w$/\=toupper(submatch(0))/

I forget about Vim's submatching expression, which is extra handy for some of those tasks that just appear to be unavoidable monotony.

Arrow keys on the macbook pro

2006-11-18T18:25:00.000-08:00

I used to have this exact problem when I used Linux on a Thinkpad several years ago. Try to use vim from the console, and the arrow keys simply don't work. There are a couple solutions to this problem, from what I understand, but I like this one b/c its simple and easy to apply on the fly whatever kind of terminal you find yourself in front of.

Lookup the key you want to override - :help terminal-options
Then type "set ~option~=~Control V~~press the key that doesn't work~"
The key is now overriden. To make it permanent, copy the command into your .vimrc (use : to view a buffer of all ex commands for easy copy/pasting).

This might sound a little complicated. Its not. Here is an example. Say that the 'up' arrow key doesn't do anything when you are in vim. No problem.

Type :help terminal-options --- Aha, I see a table and in that table it says that 't_ku' is the 'arrow up' key.
Type :set t_ku=~Ctrl-V~~up~ (where everything between ~s are the control V and then pushing the up key).
Tada, the up arrow key now works correctly.

Uncombobulating text

2006-11-03T08:28:00.000-08:00

I keep forgetting about these two tips, or rather, I get them confused. To decode some stream of data that is encoded as ASCII you can goto vim.org and read up my tip on it. Basically, install a plugin, and then run a quick search replace. I actually wrote a coder/decoder so that I could whip up custom password bookmarklets easily.

The other format is base64. I forget that ascii is base16 and base64 is, well, base64 and so has 64 different characters rather than the cleaner 16. In any event, I found this great tip for decoding base64. Don't follow the tip instructions, scroll down to the last comment on the tip, and use it instead:

:ruby require "base64"
:.rubydo $_=Base64.decode64 $_

Test Post

2006-10-29T12:57:00.000-08:00

Test post. Egad this isn't the prettiest layout, but it is somewhat console-like so I guess I'll stick with it for the time being. A nice lime green monospaced font would be nice.

Blog topic - all things Vim, and Mac Vim.