Josh Betz

Engineer, Automattician, Wisconsin Badger

pb – MacOS CLI Trick

You can already interact with the system clipboard in MacOS directly from the command line with two commands: pbcopy and pbpaste. I’ve made it even easier for myself by detecting whether there is data in STDIN — for example if we’re sending data to the command via a pipe. If so, I’ve assumed we actually want to use pbpaste. Otherwise, we want to use pbcopy.

pb () {
	if [ -t 0 ]; then
		pbpaste
	else
		pbcopy
	fi
}

You can use it like pb < /path/to/file or pb > /path/to/other/file, for example.

New Hyper Key

For quite a while now, I’ve had Caps Lock mapped to Escape. At first it was just out of convenience — as a vim user, I use Escape much more than Caps Lock. With the new MacBook Pro keyboards it’s somewhat of a necessity.

I had a great, but complex, setup that I copied from Brett Terpstra where Caps Lock was Escape if you pressed it by itself, but Control + Option + Command + Shift if you held it down with another key. This worked great for global hotkeys, especially when combined with an app like Snap, because that complex combination of keys is uncommon anywhere else. When Sierra was introduced, the super glue and duct tape fell apart, and the global hotkeys stopped working.

It looks like this was recently fixed with Karabiner Elements though; and it’s much easier now. There are some pre-made rules on the author’s website. I copied the caps lock recipe to GitHub for posterity. After installing Karabiner Elements from Github, you can automatically install the caps lock rules with a specially crafted link:

karabiner://karabiner/assets/complex_modifications/import?url=https://gist.githubusercontent.com/joshbetz/ef03e49e5d45ce34c8e23945260b122c/raw/54b65daa0377083b62a1c8219315457f087f18d8/caps_lock.json

Writing Mode in Vim

I write quite a lot of Markdown on a daily or weekly basis. From meeting notes to documentation — most of the stuff I write for work that’s not code starts in Markdown. I used to use Byword, but it’s another app to switch between. After the last MacBook refresh, there were a few apps I installed immediately and it has pretty much stayed that way.

I’ve been using Vim to edit Markdown, which is fine, but was missing some things. So, I went hunting for the proper vimscript to enable things like soft line-wrapping and spell check. Needless to say, you can do more than that.

Goyo

One of the first things I found way Goyo. Goyo does “distraction-free writing in Vim” and does most of the work — disabling line numbers, vim-airline, soft-wrapping text at 80 characters, and centering it in the terminal window. You have to enable it with :Goyo after you open Vim, but I always want it enabled when I’m editing Markdown, so I wrote some vimscript:

" Goyo
function! s:auto_goyo()
    if &ft == 'markdown' && winnr('$') == 1
        Goyo 80
    elseif exists('#goyo')
        Goyo!
    endif
endfunction

function! s:goyo_leave()
    if winnr('$') < 2
        silent! :q
    endif
endfunction

augroup goyo_markdown
    autocmd!
    autocmd BufNewFile,BufRead * call s:auto_goyo()
    autocmd! User GoyoLeave nested call goyo_leave()
augroup END

vim-markdown

Next, I installed vim-markdown for syntax highlighting. Since most of my Markdown files have the .md extension, I need to tell Vim to treat them as Markdown.

autocmd BufNewFile,BufReadPost *.md set filetype=markdown

One of the vim-markdown features is to allow highlighting of other languages in code blocks:

let g:markdown_fenced_languages = ['javascript', 'go', 'php']

Spell Check

And, finally, I enabled spell checking in ~/.vim/ftplugin/markdown.vim with:

" Spell check
setlocal spell
highlight clear SpellBad
highlight SpellBad term=standout ctermfg=1 term=underline cterm=underline

GPG & Git

Back in April, Github added support for a long-standing git feature — commit signing. Technically you’ve been able sign commits with -S since git 1.7.9, but there was no UI for it on Github. This update led folks to start automatically signing all commits, but that’s not necessary.

The git tree is a directed acyclic graph — meaning every commit references its parent — and hashed with SHA-1. In practice, this means it’s impossible to change the history of a git repo without rewriting all succeeding commits. Said another way, if you trust the SHA-1 hash of the head of the tree, you can implicitly trust the entire tree.

What does this have to do with signed commits? Well, when you sign a commit, you’re also signing all previous commits. This is one of the reasons that git originally only allowed tags to be signed:

Signing each commit is totally stupid. It just means that you automate it, and you make the signature worth less. It also doesn’t add any real value, since the way the git DAG-chain of SHA1’s work, you only ever need _one_ signature to make all the commits reachable from that one be effectively covered by that one.

You can automatically sign all tags by adding the following to your .gitconfig file:

[tag]
gpgsign = true

If you don’t tag releases, another good place to sign commits is at the end of a pull request. After a long chain, one signed commit effectively signs the entire branch. You can even add an empty, signed commit with:

git commit --gpg-sign --allow-empty

This way, there’s no need to enter a GPG passphrase for each commit, but only when you need it.

Vim Tips to Make Yourself Faster

I use Vim because it’s faster for me than other text editors. Sure, you could use vim-mode for Atom or one of the various packages for Sublime, but they all have shortcomings — and Vim works everywhere. Here are five things I do to make Vim faster for me.

Relative Line Numbers

Most people know that you can use numbers with Vim commands to make a change multiple times, across multiple lines, or multiple characters. That’s not super useful if you have to stop to count the number of lines in a block of code before deleting it, for example. I use relative line numbers in Vim. The current line is always 0. I can instantly see that a block of code is 14 lines long and d14d to delete it.

Relative line numbers in Vim

Use . to repeat the last command

This one is pretty self explanatory. Any command can be repeated with .. If you delete a line with dd and realize that you also want to delete a few more lines, pressing . three times will delete the next three lines. It may seem like a small thing, but that’s half as many keystrokes.

Use = to format code

Often, when you copy and paste code from somewhere else, it won’t be formatted properly. The = command can help here. You can either do something like gg=G to format the entire document or highlight the block of code that needs to be formatted (in visual mode) and press = to format just that block.

Make shifts keep selection

When you highlight a block of code for the purpose of indenting it, the selection is lost when you do the first shift. Often times, you need to shift it more than one position though. The following snippet keeps the current selection in visual mode after you perform a shift.

Search to find what you’re looking for

I think one of the reasons I’m slower in other text editors is that I use the mouse to browse for specific code instead of using the search function. Start searching with /. After you enter the search and press return, you can jump the next and previous matches with n and N respectively.

Next Page »