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.