romainl

Redirect the output of a Vim or external command into a scratch buffer

Usage (any shell)

Show the full output of command :hi in a scratch buffer:

:Redir hi

Show the full output of command :!ls -al in a scratch buffer:

romainl

My Vim-related gists

Long-form

• How to use Tim Pope's Pathogen
• Idiomatic vimrc (superseded by idiomatic-vimrc)
• Clipboard sharing on Mac OS X is easy
• Apprentice — The Making Of
• Vim: pushing built-in features beyond their limits
• The right way to override any highlighting if you don't want to edit the colorscheme file directly

romainl

How to use Tim Pope’s Pathogen

I’ll assume you are on Linux or Mac OSX. For Windows, replace ~/.vim/ with $HOME\vimfiles\ and forward slashes with backward slashes.

The idea

Vim plugins can be single scripts or collections of specialized scripts that you are supposed to put in “standard” locations under your ~/.vim/ directory. Syntax scripts go into ~/.vim/syntax/, plugin scripts go into ~/.vim/plugin, documentation goes into ~/.vim/doc/ and so on. That design can lead to a messy config where it quickly becomes hard to manage your plugins.

This is not the place to explain the technicalities behind Pathogen but the basic concept is quite straightforward: each plugin lives in its own directory under ~/.vim/bundle/, where each directory simulates the standard structure of your ~/.vim/ directory.

romainl

This is a list of custom pseudo-text objects for Vim.

Note the use of "pseudo", here. Conceptually, text object are "special" motions but there is no proper mechanism dedicated to creating text objects, specifically. We are left with the generic mechanism succinctly described under the easy-to-miss :help omap-info.

Writing one's own pseudo-text objects and motions is a great way to extend Vim without perverting its nature ;-).

---

My Vim-related gists.

romainl

FOREWORDS

I don't mean the snippet at the bottom of this gist to be a generic plug-n-play solution to your search needs. It is very likely to not work for you or even break things, and it certainly is not as extensively tested and genericised as your regular third-party plugin.

My goal, here and in most of my posts, is to show how Vim's features can be leveraged to build your own high-level, low-maintenance, workflows without systematically jumping on the plugins bandwagon or twisting Vim's arm.

---

Instant grep + quickfix

romainl

Super cheap git blame

git blame current line

:GB

git blame range

:7,13GB

:,+5GB

romainl

function! Substitute(type, ...)
	let cur = getpos("''")
	call cursor(cur[1], cur[2])
	let cword = expand('<cword>')
	execute "'[,']s/" . cword . "/" . input(cword . '/')
	call cursor(cur[1], cur[2])
endfunction
nmap <silent> <key> m':set opfunc=Substitute<CR>g@

" Usage:

romainl

Tags

Setup

Tell Vim to look for tags files:

• in the directory of the current file,
• in the working directory,
• and in every parent directory, recursively,

romainl

Off the beaten path

What is &path used for?

Vim uses :help 'path' to define the root directories from where to search non-recursively for files.

It is used for:

• gf, gF, <C-w>f, <C-w>F, <C-w>gf, <C-w>gF,
• :find, :sfind, :tabfind,

romainl

Linting your code, the vanilla way

You may want a linter plugin to lint your code in Vim but you probably don't need it. At least try the built-in way before jumping on the plugin bandwagon.

Defining makeprg

autocmd FileType <filetype> setlocal makeprg=<external command>

This autocommand tells Vim to use <external command> when invoking :make % in a <filetype> buffer. You can add as many similar lines as needed for other languages.