Some Handy Notes For Vim

Vim has many things going for it. Not small detail things. All the small detail things can be customized. Vim is different in major ways.

Modern life is filled with passwords. I personally have hundreds of accounts and if there is any hope of me using good unique passwords, I simply can not remember them all. Some people use fancy password managers. The technique I use is to simply keep them in a text file which I manage with Vim. Of course keeping your passwords in a text file sounds like it would have many security deficiencies and were it not for Vim’s fantastic features this would not be a good idea. Here’s what I do.

Since I use this pretty often, I set up an alias to do all the hard work. The alias looks like this:

If you use screen/tmux a lot, you sometimes can get into trouble opening your password file in two different terminals which is not ideal. I now use the following instead of the last line defining the alias shown above.

This format of the alias definition shows clearly all the special Vim settings that I use. This suppresses Vim’s normally helpful behavior to save everything you do in a somewhat insecure way. This does not allow a viminfo file, nor backup creation, nor swapfile use. The option for tw (text width) is so I don’t get automatic line feeds since I’m not typing prose. Finally the foldmethod and foldclose options set up folding.

The idea with the folding is that when the file is opened, none of the passwords will be visible. Only when you search for the password you want will it be revealed under the fold. The point to this is that if you have to look up a password in an insecure place, people in the vicinity won’t be able to gawk at all your passwords. To make this work you need to exercise some discipline with the format of your password file, but it’s not complicated. Here is an example of a password list with the correct formatting.

Things to note: Each record begins with a -. This is used to let the folding know that this is a record separator. It is not indented. Next notice that all the other lines are indented. You can make it tabs or spaces but it’s a good idea to be consistent. I use four spaces. You can see that I don’t just store password data, but I also often include pretty full details about what I need to remember about a company or account. In the infamous ATT example, I keep a record of all the times their stupid web site was down. I also keep particular custom credit card numbers that I only use with this vendor here (Discover used to provide this capability). Since it’s Vim, you have complete flexibility. Since you’re using folds, it’s perfectly reasonable to write as much as you want. When you save this file and then use the alias (pw as defined above) to edit it, it should look like this:

As you navigate around the document, only the fold that your cursor is on will be open. Since I have so many accounts in this file, I generally hit / right away and search for the account I’m interested. Because of this, I’m pretty careful to always use lower case, or, as with the AT&T example, multiple options if I think I will forget.

Now that you have a nice system for creating a very straightforward text file for storing your passwords, it is probably a very good idea to impart some cryptographic protection. It turns out that Vim comes with an encryption mechanism built in.

To encrypt a file with Vim (remember, this handy feature works with any file you want to keep private), in edit mode type :X. It should respond with Enter encryption key: which you should do. Note that a long pass phrase with spaces is allowed and probably a good idea. Perhaps something Dylanesque like "2 much confusion, I can’t get no relief." It will ask you to Enter same key again: to make sure you really know how to type what you think you’re typing. Now the encryption key is set. To encrypt it, just do a normal :w. It should say something like "pw" [crypted] 34L, 1060C written where the "crypted" flag lets you know it’s no longer being saved as plain text. Now when I do less pw to look at the file from the unix command line, it says "pw" may be a binary file. See it anyway?". It sure is a binary file:

That’s all that you get to know about the file from examining its encrypted contents.

In the future, when you use the pw alias, it will ask you for your pass phrase. Once you enter it, you can edit as normal and when you’re done, you can save it as normal. To make a file stop being encrypted, just do :X as before, but just hit enter for the passwords. Then use :w to save it as plain text again. This is also how to change the password, for example, if you think it became compromised.

The question is whether to put hard returns in as you go or keep each paragraph continuous. I like to see the hard returns and can deal with them fine. But when you need to export your composition to a word processor or a web form box, it can be necessary to join the lines in a paragraph. The following works pretty well for that:

The last one sorts out any bullet lists you may have had. If you don’t need bullets worked out:

Often you get a file that comes from a sensible word processor (maybe even vi itself). This text only puts hard returns at the end of paragraphs. If you need hard returns put in everywhere so that you can deal with the text in vi or other line oriented tools, here’s the sequence. This routine basically makes a textwidth of 75.

To execute this, go to a line that needs some hard returns (don’t start on a small line that doesn’t need any!) and use @q. Using @@ will cause it to continue. Since the number of lines is not known (you’re creating new ones all the time with this), it’s tough to automate it completely. Try 500@q and see if that gets it. It should stop at the end if the search is not found, but this could depend on the WRAPSCAN setting.

Also note that the gq command will automatically sort out text like this macro. Probably best to stick with that.

Vimium is an extension for Google Chrome that makes the browser interface much less horrific. Here are some useful shortcuts for it.

First you need to understand how to get make to work for you. Use set makeprg=make to set your make executable (gmake or maybe a make\ \CC=gcc). Set up your Makefile or whatever your make program likes.

Test the make process from the command line outside of Vim and when it works fine, it should work fine in Vim by using the :make command. This can be shortened to :ma for the impatient.

After make runs, if there are errors, Vim takes you to the first of them. To move to the next error use :cnext or :cn. Also there are clast, cfirst, and cprevious.

Some people like to see line numbers (with :set number or :se nu) but I find it pointless since you can always go right to where the issue is by typing the line number of interest and gg. So to go to line 15, type 15gg.

I haven’t used it but there is also support for exuberant-ctags (try apt-get install exuberant-ctags). And maybe look into :cscope (try apt-get install cscope).

Look at the section on customizing Vim’s syntax highlighting where I show specifically useful things about C++.

I do not like tabs because to me it seems like non-obvious behavior. There is, or may be, maybe not something invisible lurking in your document. When moving around a document, having it suddenly jump is unnerving when you didn’t tell it to do that. It is easy in Vim to not use tab characters and get the same indentation functionality.

The general form of a search and replace operation is: :1,$s/findme/repwithme/g

If Vim is missing a command that you think should be present, you are free to fix that.

Here’s an example that inserts a custom formatted date into your document.

This will put 2017-08-12~Sat in your file.

Let’s say you have a script that needs the user to contribute some text. You could use simple things like Bash’s read built-in but maybe you want the program to allow fancier editing. For example, I have a program that processes my blog and one of the modes allows me to compose an entry in the middle of this running program.

The "visual" mode is just a mode where you can highlight text and then do things to it. And they say vi is old fashioned! Just press v and do the move around bit. You can also do Shift-V for linewise selecting and ctrl-V for blockwise selecting. Isn’t that great?

Well what are you gonna do with that highlighted text? d :: Gets rid of it ~ :: Changes its case "miXED up!" is now "MIxed UP!" U :: Uppercase "Mixed up!" is now "MIXED UP!" u :: Lowercase "Mixed up!" is now "mixed up!" y :: seems like copy - you can then use p to reinsert it o :: go to the other end of the selection to modify that point J :: joins the selected lines of text together <<:: Indents it to the left. >>:: Indents it to the right.

To set the digraphs flag use :set dg This allows you to do cool stuff by typing part one, BS, and then part two.To see what your options are, check out the codes with :dig Sometimes this doesn’t work out on some displays and some terminals, etc. But I have little doubt that Vim is planting the correct character codes for your encoding as you specify.

Another one that I like is the tw setting. I usually use 70, like this:

Why 70? Voodoo superstition. Anyway, this adds a hard return after the last word that was completed before the column number you specify.

This is a list of some of the relevant things that should be compiled into Vim. This can be discovered by using the :ve command (version). (see :help feature-list)

So on 16 color terminals, just use the number. On 8 color terminals, * is bold to modify. Also the names are valid replacements for the numbers.

To see details about what is going on with a style you like:

Sometimes you see some weird irritating syntax in your program and you’d love to fix it but you have no idea what it is being controlled by. This nice tip will set up the F10 key to provide more detailed information about the syntax at the cursor position. It looks like this.

A lot of times after you find that a certain style is being used, it then turns out that this style is "linked" to another. To make your own link to a better target, or unlink it and make your own version look at something like this.

Here the first line unlinks whatever the Boolean group was doing. The next line says that the Boolean group should behave like the definitions for the Constant group.

Note that for C++ specifically, there is a special filetype=cpp that goes beyond the filetype=c that adds things like class and true, etc. So make sure you’re not fighting with something like that.

Are there some things that should be highlighted but are not? Maybe you want common calls from a library you use a lot highlighted in a particular way. This nice C++ extension syntax file is a good model for how to add your own items to highlight.

Generally, for simple highlighting, the idea is you want to add some keywords to a named keyword set. Then link that to the type which renders the way you want this set to look.

I have no idea how case and default didn’t get in the default; is this not kosher C++? But the C++ container types are just some examples of ones I happen to be using right now. If you look at the vim-cpp-modern vimrc, you’ll see that there are, of course, 23k keywords. Just kidding. I think.

Sometimes you need to support a completely new type of syntax highlighting and for this you’ll want to prepare a syntax file just for this new format. Syntax highlighting is actually done by sourcing the syntax file. So if you’re testing your new syntax file out, just source it.

Sometimes you want to start Vim with a particular non-obvious syntax. This works.

The natural place for personal custom syntax files is here.

With that you can just :set syn=gg

And to make it automatic, you can put something like this in ~/.vimrc.

This page has a pretty good example of installing someone else’s syntax for exotic needs. In this case, it’s CNC G-codes — ahem, not all that exotic!

That last resource may be able to be put comfortably in your ~/.vimrc file, but I’ll show it here to provide a different approach.

Note that I also added the *.gcode extension because that was weirdly missing (e.g. Cura exports to that).

The actual details of creating your own syntax are pretty murky due to the profound efficiency of Vim’s syntax. But basically you need to define some stuff with syntax (or syn or synt, etc.) and then you need to link that to some highlighting style with highlight. The syntax specifier can look for a keyword (or many specified on one line). It can look for a regular expression match. It can also look for a range which I didn’t use.

Here’s my rough attempt to make a syntax highlighting file for GeoGad.

This isn’t 100% correct, but it works pretty well and makes editing gg code a real pleasure.

Some time in 2014 my Vim started to get very laggy. I could type entire sentences before they would show up. I discovered that this was curable with set syntax=off. Unfortunately, I like syntax highlighting.

After a tiny bit of research I found some other things that can be done to help.

Unfortunately these help but don’t help enough. The first one is interesting since it changes the regular expression engine to an older one that is actually faster in many situations.

My Vim:

Still working on this.

On newer Vim, I have found that running external commands using :!<cmd> will work, but when the command finishes, it just drops to a shell prompt with Vim never waking up from being suspended. It can be recovered with the shell builtin fg (foreground). But this is extremely frustrating for things like !make which can be run hundreds of times a day. The best lead on this, and I think the solution is this setting:

The help documentation, worth noting because it’s not an easy thing to search for, says:

Vimb is a Vim-like browser. Like all modern web browsers it is based on Webkit. It is like the old Vimium and Vimperator plugins but it is a stand alone client. Here’s what I did to get it working.

First you need to sort out dependencies. I don’t know exactly what they are but this definitely was one for my system.

Then obtain the source code.

Here is how to compile in a safe way so that it does not actually mess with your system-wide software.

It is by design a bit bewildering to the ignorant masses. Here’s how you can read the man page that will cure your ignorance.

If you like Vimb and want to keep it, I found that it seemed to behave when I just dropped the executable in a directory in my path where it runs just fine.

Oh wait. No. That’s wrong. It needs a library that’s still lingering in /tmp/, so probably better to check out the repo to a non-volatile location and carry on as described.