vim

Vim/vundle and its issues

Pi

I have since fixed all of my vim installations: both laptops, the entertainment centre, and my office desktop in both Cygwin-64 and Mint Linux versions.

In Cygwin, there seems to have been two versions of vim installed: one that doesn’t understand Bundle commands and one that does. Both look for vimrc files in different files, and one of them looks in ~/.vim/vimrc — which is a directory on my distro, due in large part to the installation of Vundle.

According to GitHub’s terse description of Vundle, “Vundle is short for Vim bundle and is a Vim plugin manager.” OK, so it manages plugins, or rather scripts. It allows you to do this in your .vimrc file. It claims it can take advantage of vim-scripts.org to install or search for all available scripts.

When I did the recommended “vim +BundleInstall +qall” command, it installed everything in sight (or so it would seem). Of course, being unfamiliar with vim, and being far more experienced with vi, the first thing I really noticed was the fact that some of the movement keys were re-mapped which I was used to using.  The above screenshot is taken from Linux Mint 14 after configuring Vundle. Take note of the snazzy status bar, the syntax highlighting (that’s stdio.h you see in the illustration), the line numbering and the highlighting of the current line where the cursor is placed.

While it is not my style to be enamoured of new stuff because it is new, the syntax highlighting is better than Elvis, and it has language support from several new computer languages. By “language support”, I  mean, for example, if you are editing HTML, there are commands that change tags, or change the text between the tags with a few keystrokes. Elvis cannot do that without some serious key mapping, to my knowledge. The way vim appears to do it is thorough its scripts, as they appear after installing Vundle. And of course, you can map keys under vim as well, and the key mapping appears more sophisticated.

vim and compatibility with vi

Pi

Yes, in my hacking and snooping the config files, I found “set nocompatible” in the .vimrc under the dotfiles from the Git repository. I looked this up, and this would appear to be the heart of my woes about key mappings. “set nocompatible” means set the key mappings in a way that is incompatible with traditional vi (and more along the lines that vim was designed). So, is it a simple matter of just commenting this out and adding “set compatible” to get what I want?

Ah, no, dear reader, because if I do that I break nearly every plugin (or so it seems) in the repository. When I tried to do this, I got error messages left, right and centre. vim has its own key mappings, its own implementation of the :map command, and making it compatible with traditional vi would bring the vim plugins to its knees.

It is somewhat better to go through the mappings.vim plugin and comment out anything you don’t like (for me, nearly all of what’s in there). I advise commenting out rather than deleting, since it would be nice to take advantage of the commands as syntax suggestions in case I want to do my own mappings some day.

… being a vi/vim purist ….

Pi

I had set up and edited websites using traditional vi with only the mappings and settings I placed. Mostly, but for a few lines in my .virc, .elvisrc, or .vimrc file, I was happy with the default settings of traditional vi that I needed few mappings, and anything I wanted to do in a single keystroke that needed mapping I would just map the key as I was editing. This meant I could get along with any vi version, even the stripped-down BSD vi editor that is the default at my ISP. I’ve never complained about their editor. I could always set things up in a way that worked around whatever limitations of the editor I was using.  I could rely on the fact that all vi versions had basic key mappings that were common, and characteristic of vi in general. In addition, all vi clones had the ability to map keys to user commands using “:map”.

I was mostly an Elvis fan (the vi clone, not the singer), since it was pretty “souped up” while not having settings that slowed it down or interfered with existing default key mappings. For a while, my .elvisrc had some key mappings I wanted, and had the ability to map key combos during insert mode. Elvis had a help system, based on HTML, with links to other files in the help system. Elvis could navigate HTML, and more. The Elvis project was abandoned for some years, but seems to have been revived around last year, and there is currently some activity in the GIT repository regarding Elvis. I hope people see value in it, since it was a pretty decent editor.

vim (short for “vi improved”) has been around for, I think, more than a decade, and has caught on to the point that it appears to be the de facto vi most developers use. It has coexisted with Linux, and in most Linux distros, it appears to be the default vi used. Ever since the mid-90s when I began using Linux, I had made, as one of my adjustments to the default installation, an uninstall of vim, and an install of Elvis in its place.

Then, I went on ITunes, and downloaded material from a Harvard Open Course called CS 50, and learned that vim had, for many years, a number of plugins and other weird stuff I had not seen in vi before.  I was shown in a video how graceful and skilled the demostrator was in using these plugins (although most of his commands could be replaced with traditional vi commands with the same number or fewer keystrokes), and a killer text interface that got me interested. The installation commands I was to use to begin my journey was:

> cd ~
> git clone http://github.com/thenovices/dotfiles
> ln –s dotfiles/.vim* .
> git clone https://github.com/gmarik/vundle .vim/bundle/vundle
> vim +BundleInstall +qall

While there were some great improvements to the interface, some of the packages introduced a slew of key mappings which clobbered a lot of default mappings with new ones. CTRL+B (originally the command to move backward 15 or so lines) became something which opened new colon command lines (even multiple colon command lines). Some aspects of the new vim dotfiles also greatly slowed down the program, as well as imparting strange behaviour when the program is first called with a filename. That would include quickly jumping around crazily and making random text inserts. This was observed in Linux as well as Cygwin. The only choice then was to issue a :q! command and leave the file un-edited. In case you were wondering, “vi -r” was not used, although it appeared as though vim was performing a recovery on a file that needed no recovery, resulting in a mess.

It would appear that the plugins are great for new users so long as you don’t know any vi commands. That way, you don’t have to hack your way through the config files like I have to in order to coax more traditional behaviour while taking advantage of its many good points.  One of them being the ability to use multiple windows on the same interface. Most of the new keystroke command mappings do not seem like improvements to me, after all, a keystroke is a keystroke. But a new user would not be troubled by it, since there are no prior habits to unlearn. Although, if a new vim user moves to a system which uses traditional vi, he or she will find trouble.