One of the obscure, but tremendously useful features of Vim is an undo tree.
You would expect Vim to have a simple stack for undo and redo actions, but it’s
much more complex than that: Vim keeps track of every change you made in the
current session, making it possible to access change history beyond basic
Default interface for accessing far out branches of the undo tree leaves to be desired, but that’s where Gundo comes in.
Gundo provides an easy to use interface for navigating history branches. In the
screenshot above, I am previewing a diff in one of the undo tree branches
As per author’s recommendation, I mapped the plugin to
F5, which seems quite
convenient to me:
nnoremap <F5> :GundoToggle<CR>
Usage is quite easy.
F5 opens or closes the undo tree,
k are used
to travel through changes. Enter key applies the changes.
About a year ago I stumbled upon an article explaining the difference between Vim tabs and buffers. The author emphasized that tabs are merely window layouts, and therefore one-file-per-tab idea I was used to at the moment just wasn’t proper. Instead, author suggested the use of buffer commands to switch between multiple files. I decided to give it a shot, and here are some ideas I would like to share after switching to the use of buffers.
Buffers are open files (they also may not be associated with any files), but they’re not necessarily visible at any given moment. In Vim, windows are not linked to any particular buffer, so you can easily cycle through buffers from within any window.
First and foremost, you probably want to add
set hidden to your
This option lets you switch between buffers without having to save files.
At it’s basics, you only need few commands for operating buffers:
:lsto list all buffers for this session.
- To move between next and previous buffers use
:b partial_buffer_namefor navigating to the buffer of your choice. Buffer name auto-complete is supported.
- You can also use
Nis a buffer number to jump to a specific buffer.
- Get in a habit of closing buffers you will not use with
The hardest thing about stopping to use tabs and switching to buffers instead
is not having the visual aid: I was used to having a list of files always
available at a glance, at the top of my screen. To check what files I’m working
on now - I have to hit four keys:
:ls (fourth being “Enter”).
Not surprisingly, this taught me to be more mindful about my editing experience. I usually have a clear structure of the files I’m working on in my head. And if the list is getting to long to easily remember, then I’m probably doing something wrong: time to take a break and reset my Vim session.
The experience overall reminded me of my recent switch to blank keyboard key caps: with no inscriptions to aid you, I first felt a bit at loss, especially with they keys I couldn’t find without looking: like function keys or special symbols. But after some time with the blank key caps, I improved my typing skill, and know where even the most obscure characters hide. The switch helped me to improve my typing experience overall.
With Vim, it’s a similar story. After getting past the initial confusion, I achieved high level of awareness about my editing sessions. It didn’t make the editing process any faster, but instead much more satisfying.
But you already new that, since Vim isn’t really about speed.
It is my fifth year working as a professional software engineer, and I think it’s a good time for me to share a few tips, dos, and don’ts I learned throughout past four years. This is the first article in a series of three, and it focuses on development process.
Moving towards becoming a senior engineer, I noticed paying more attention to the impact my work produces. These days I would much rather compile a number of small simple changes to “wow” the users, as opposed to building unnecessarily complex nice-to-haves. This sounds simple and straight-forward, and some reader might even say “That’s silly, everybody knows that”. However significant number of engineers I meet don’t concentrate on how much impact they produce.
It’s easy to get caught up in a daily routine: you close an issue after issue, there’s a stable flow of requirements from the business meetings. It’s not always easy to know when to stop and think “Do I really need to do this?”.
Get the priorities right
Divide amount of impact task produces by amount of effort you’ll have to put into completing it. Arrange the tasks by this factor.
More often then not you can drop items with low impact/effort ratio.
Separate what is needed from what is asked
Know who the stakeholders are for each task, feature, or a project you work on. Understand their underlying motives. Anyone can fall a victim of an XY problem, it is your responsibility as an engineer to make sure that stakeholders ask for what they actually need.
Know when to say “No”
In the very beginning of my career I gladly took every single task thrown at me. It soon became an issue: work that actually needs to get done is not getting done quickly enough. Knowing when to say “No” is an art that takes practice.
Think about your work
Beware of routines, repeating the same workflow time after time is damaging when it comes to building software. Stop each time before you proceed to the next step, and ask yourself if you’re performing the task in the best way possible. Be mindful about your work.
Be a catalyst for change
Be the first to promote the change. Did you notice a poor practice on a project? Begin a more efficient practice (if it’s appropriate based on your role in a team of course). Don’t go on telling people how wrong what they use is. Show everyone how the new way is better on practice, and your colleagues will adopt successful trend.
Don’t fall a victim of deferring responsibility: be aware that when multiple people are involved, every member of a group relies on other people to get things done. Be the one to take on responsibility when it’s unclear who should.
A couple of months ago I discovered apparix: a set of commands which augment
cd with bookmarks. It really is an amazing feeling when you zap between
multiple directories far away just with a couple of keystrokes! Apparix
provides three commands I use daily:
suggests aliasing last one to
als). Here’s how I use it:
$ pwd /Users/ruslan $ apparix --- portals --- expansions --- bookmarks j dotfiles /Users/ruslan/.dotfiles j blog /Users/ruslan/Projects/ruslanosipov.github.io $ to blog $ pwd /Users/ruslan/Projects/ruslanosipov.github.io $ cd source/_posts $ bm posts added: posts -> /Users/ruslan/Projects/ruslanosipov.github.io/source/_posts $ to dotfiles $ pwd /Users/ruslan/.dotfiles $ to posts $ pwd /Users/ruslan/Projects/ruslanosipov.github.io/source/_posts
The example above is self explanatory: you can see how over the span of a year apparix saves hours of navigating directories you frequent.
If you don’t like reading manuals, installation might be a confusing. But in reality it’s straightforward, you just need to add some functions or aliases to your shell’s configuration file.
apparix using your favorite package manager, and then pipe examples
apparix offers into your shell’s
apparix --shell-examples >> ~/.bashrc
.bashrc (or another corresponding configuration file), and pick the
preferred way of using apparix: you’ll see functions for bash and aliases for
csh given as examples. Pick whatever works for your shell, source your
file, and you’re all set!
Ranger is a lightweight but powerful file manager with Vi-like key bindings. It shines at exploring file trees, looking for specific files, and performing bulk operations on folders and files. Three column layout will be very similar to Mac OS X users: center column shows contents of the current directory, left column lists contents of a parent directory, and the right column contains preview for the selected file or folder.
Ranger supports movement with familiar to Vi users
has internal command line which is invoked with
:, as well as many other
features and key bindings similar to Vi. Another great selling point - Ranger
can be extended with custom commands and key bindings. Utility is written in
Python, therefore all the commands are nothing more than Python scripts.
Ranger is easy to install and can be found in most public repositories, just
ranger package using your favorite package manager. While you’re at
it, you may want to install some external utilities to help Ranger properly
display file previews (list is taken from ArchWiki page on Ranger):
highlightfor syntax highlighting.
img2txt) for image previews in ASCII.
perl-image-exiftoolfor media file information.
pdftotext) for PDF.
transmission-clifor BitTorrent information.
w3mfor image previews.
After all the dependencies are installed, quickly start up
ranger, exit it
q, and run
ranger --copy-config=all to generate configuration files in
Here are a few of the key bindings and commands I found useful:
- Use spacebar to select files one by one. By selecting multiple files, you can
perform bulk operations on them. Use
Vto perform visual selection. Lowercase
vreverses current selection. For instance, you can run
:deleteafter selecting multiple files and folders.
- As mentioned above, execute
:deleteto remove currently selected file (or files).
- To fullscreen a preview window, hit
iagain to return the preview window to it’s normal size.
Gallow you to jump to the top and bottom of the file list respectively.
zhto toggle hidden files display.
- As in Vim,
/searches for a file in a current buffer, while
Nlet you navigate to the next and previous matches respectively.
:filterallows you to only limit your view to the files matching a pattern. It’s also interactive - changes are applied as you type.
If you’re an avid Vim user, you’ll find using Ranger surprisingly intuitive. Otherwise you might get confused and scared away, probably for a good reason. Ranger is designed to provide Vi-like feel for file browsing, and it does that job well.