Sunset (GitHub: amdt / sunset, License: Vim) by Alastair Touw automatically sets background when the sun rises and sets. It works with themes that have light and dark variants, and Alastair points out both Solarized and Hemisu support this.
Makeshift
Makeshift (GitHub: johnsyweb / vim-makeshift, License: Vim) by Pete Johns detects which build system :make should use by setting 'makeprg' based on the files present in the working directory. The built-in build systems are Make, Rake, SCons, Ant, Maven, CMake, and BJam, but more can be added by setting g:makeshift_systems.
If you're looking for a good way to learn new Vim skills, then you can discover a lot from someone's ~/.vimrc. Searching for dotfile repositories on sites like GitHub is a good start. On one such dotfile diving session I noticed how often set hidden crops up. The documentation for set hidden (:help 'hidden') isn't exactly easy to follow:
When off a buffer is unloaded when it is abandoned. When on a buffer becomes hidden when it is abandoned. If the buffer is still displayed in another window, it does not become hidden, of course. The commands that move through the buffer list sometimes make a buffer hidden although the 'hidden' option is off: When the buffer is modified, 'autowrite' is off or writing is not possible, and the '!' flag was used.
This is a bit much for a tutorial series called "Vim 101", so I'll break it down:
I typically write tests for the software that I work on. Since I started writing usevim I've noticed a lot of plugins don't include tests of any kind. Even widely used, respected, and venerable plugins ship without tests.
Are Vim scripts somehow different to other software so they don't require automated testing? I'd argue that they're not special, and should be tested.
Vim doesn't include anything specifically for writing tests, but there are a few popular scripts that implement unit testing frameworks. For example, vim-unittest by Sam Simmons is a pretty solid implementation. Tests are run like this:
Ozzy.vim (License: MIT) by Giacomo Comitti allows files to be opened quickly and easily. An algorithm is used to determine which file to open: it can be set to use most recent, most frequent, or context. The last means the closest to the current working directory.
Files are opened with :Ozzy <file name>, and partial paths are supported. Ending <file name> with a forward slash will cause Ozzy to interpret the file name as a directory and open all of the contained files.
Ozzy seems like a good way to quickly switch between files across different projects, or to switch between files in a very large project.
Last week we looked at getting Vim running in Windows. Although there are more platform-specific issues that I could discuss, I thought looking at using Vundle and Pathogen in Windows would be useful.
If you haven't used Vundle or Pathogen before you might be wondering what the advantages are. I like them because they make it easier to quickly try out a plugin, and to install my favourite plugins on a new machine or server. They make it easier to keep multiple machines in sync -- this isn't useful if you mostly only use one machine, but if you're switching between a work desktop and your home computer or laptop then it saves time.
Vundle
The Vundle for Windows documentation explains how to get Vundle running. Basically, to make the Windows environment look more like what Vundle expects, the Git and Curl binaries must be installed. Once that's done, steps two and three from the Vundle Quick start documentation should be followed, which will result in the creation of a _vimrc with the appropriate Vundle settings.
It's actually quite difficult to use Vim without writing a script. We install plugins all the time, and the superficial complexity of the average plugin's source code may make writing Vim scripts seem impenetrable. However, believe it or not you've probably already written a Vim script in the form of your vimrc file.
Each line in a vimrc file is executed as an Ex command line. Everything from your vimrc to plugins is derived from these humble Ex origins. However, since Vim 7, several more advanced language constructs have been added -- including datatypes such as Lists and Dictionaries and even object-oriented features.
Vim's scripting language is generally referred to as "Vim script", but "VimL" is a popular synonym.
Although Vim is naturally optimised for writing software, I actually use it as a general purpose editor for all kinds of writing. Write.vim (GitHub: Soares / write.vim, License: Vim) by Nate Soares is an attempt to cater to this need. When in "writer mode", set by typing :WriteOn, Vim is configured to move screen-wise, hide line numbers, and turn spell checking on.
sha3.vim
There's been a lot of talk about SHA-3 recently, since NIST announced that Keccak has been selected as SHA-3. sha3.vim by Yukihiro Nakadaira is a port of Keccak-simple32BI.c to Vim. Saving gist: 3848180 to ~/.vim/autoload/ will install it, and SHA-3 hashes can be generated with sha3#sha3_512('foo').
Vim is available for many platforms, including Windows. Although it has a strong association with Unix, thanks to the heritage of vi, Vim was originally released on the Amiga (my favourite computer and OS of all time). Over the years Vim has been adapted to various systems and has platform-specific features. In this tutorial I'm going to introduce using Vim for Windows, and discuss a few Windows-specific options.
Download and Installation
To download Vim for Windows, go to Vim's site, select Downloads, then scroll down to PC: MS-DOS and MS-Windows. I usually download the gVim executable installer, which has several options -- make sure you click "Create .bat files for command line use" if you want to run Vim from with cmd.exe:
HappyEdit is a proposed project to remake Vim using modern web technologies. The project was started by Per Thulin who previously worked at Flattr. Per is looking for $10,000 funding to develop the application, but already has an initial version which is demonstrated in the Indiegogo video.
In terms of a crowdsourced project, the perks aren't particularly exciting. The most interesting aspect of HappyEdit is Per's user interface ideas -- rather than slavishly duplicating Vim he's trying to do new things with the web-based GUI.
butane.vim (GitHub: Soares / butane.vim, License: Vim) by Nate Soares, originally based on Vim Tip #165, adds a command called :Bclose which closes the current buffer without rearranging the window layout.
This plugin checks the modified state of the buffer, and displays an error message when closing an edited buffer. The :Bclose! command can be used to force a window to close.
longline.vim
longline.vim (GitHub: Soares / longline.vim, License: Vim) also by Nate Soares highlights lines that are too long. The line length can be set based on filetype, and it also has hooks for updating statusline.
