Visually seeing all (book)marks in Vim

I attended a friend's masters thesis defense (congrats, Ducky!) and it made me think about bookmarks in editors. For TextMate, it has a simple bookmark feature: press Cmd-F2 to leave one, and then cycle forwards or backwards through them. Vim, on the other hand, has bookmarks labeled by letter, which can be per-file or global.

With TextMate's solution it is quick to set a mark and requires no thinking. The problem, though, is you have to cycle through the bookmarks blindly until you find the one you want. That can be annoying if you are leaving marks behind when you are jumping around following control flow through various methods and classes.

Vim has the opposite problem. You have to assign a bookmark that has not been used previously, but it does allow you to jump directly to marks. If you run the ``:marks`` command you get a list of every mark currently set, complete with line/column/text info. So if you know you set a mark but not sure which one exactly, you can try to do it based on what text is on that line. You can also jump directly back to another file if you set a global mark there, allowing you to track your movement between files. So you trade off the ease-of-use of just leaving any random mark for the ability to be specific and get a list of all known marks.

More fun with building Vim 7.1 on Mac

Got to have more fun with trying to build Vim on OS X last night. I noticed Vim 7.1 was released so I decided to update. That turned out to be a mistake.

Turns out the Aap build file had an "unrecognized item" of build-resource. I don't know Aap but it looked like a target with that name existed so I didn't know what was going on.

At this point I have given up on the Aap building procedure for Vim. So I got the svn checkout for Vim and built using configure/make. Specifically, I went into the src directory and ran ./configure there. To build with Python interpreter support make sure to enable it and to specify the location of your Python config ($prefix/lib/python/config). Then make. If you went with a GUI version then ``make install`` by default installs into /Applications. But if you specified --prefix it will put the Vim.app directory there.

I did replace the icons with the set I mentioned in my last Vim post. If you happen to view the icon for the app before doing the replacement OS X will cache the old icon. Make sure to right-click on the app and choose "View Info", click on the icon in the upper-right, and hit backspace to delete the cached version.

Getting gvim compiled under OS X

Getting gvim installed from source turned out to be harder than I was expecting. Because of that I figured I would share how I managed to get it finally to work so that nobody else has to go through the hassles I did in order to have a version of vim that is all patched.

1. Fetch the vim code using Aap. That gets you the source, the latest patches, etc.
2. Download some icons. For some reason the compile kept failing because vim couldn't find any icons for OS X. So I downloaded some that I liked.
3. Edit your vim/src/main.aap file. Search for ``gui_mac.icns`` and replace it with ``app.icns``.
4. Copy your app icons into vim/src.
5. Build/install using Aap. Don't bother trying to set PREFIX as it seems the eventual path into /Applications is hard-coded somewhere.
   
6. Copy some doc icons over. Copy the doc icons to /Applications/Vim.app/Contents/Resources/doc.icns .
7. Update the vim runtime files. Best way is through Aap.
8. Alias ``vim`` for your console. Set the alias to /Applications/Vim.app/Contents/MacOS/Vim .

The key thing in all of this is that (at least for me) the build couldn't find the icons for gvim and so I had to provide some and change their names. I tried uncommenting in the main.aap file the lines that said it would detect any icons I added, but I got Aap errors instead.

I am the official maintainer of the Vim syntax file for Tcl

Back in November 2006 I sent Bram Moolenaar a patch to the syntax file for Tcl so that Vim would get better support of some commands' optional arguments. Doing that ended up with Bram saying that he had made me the official maintainter.

Now, irony aside of having a Python developer maintain the Tcl syntax file, I warned Bram that I was not in any way a Tcl enthusiast or expert. I had just written some Tcl code to learn the language and noticed the syntax highlighting was incomplete.

But I figured that if no one had discovered the shortcomings I had then it wouldn't be that much. Hell, the last guy had retired and it had not made a difference. So I told Bram I was willing to be the maintainer since I have passing knowledge of how to define Vim syntax files thanks to my work to create Python's python.vim file automatically. Plus I figured I owed the Vim community a little volunteer work since I have been using Vim for years along with havning never donated any money to the project (poor university student and all).

But I had not heard back from Bram about the change. And I had a svn checkout that never touched the Tcl syntax file every time I updated. I was rather disappointed that my change had not gone in. I pretty much dropped my idea of learning more Tcl by writing a Tcl script to parse the manpages of Tcl to auto-generate the syntax file.

Then today happened. Since my hard drive got replaced I was deciding how I wanted to update Vim (probably going to use Aap to get Vim). I noticed that the download section has a separate part that tells you how to update the runtime files themselves without touching Vim itself using Aap. That made me wonder if there was some disconnect between the svn tree and what was actually put out.

Sure enough, the runtime files that Aap fetches from Vim's FTP server are much newer than what is in the svn or cvs repositories. Turns out I am the official maintainer of the tcl.vim file after all. Guess I should put that Tcl script back on my todo list and eventually get a Google Code project open for it.

Now it just makes me wonder where Vim's development is done if the svn repository is out of sync with what is on the FTP server. Just goes to show that every open source project has its own development style.