Use HOME as your GOPATH

How and why I normalised my Go paths and personal/local home paths.

Like many people, I have my own scripts and stuff in a bin directory in my home directory. Actually it’s a symlink to ~/.local/bin because I saw there was a ~/.local/share which some programs use to store user-specific things and I wanted to be consistent.

Then I saw some people have ~/bin and ~/src and I thought that looked like a tidy way to organise things. So far my approaches have been putting code in ~/Scripts ~/Projects/Programming or more recently ~/Work and ~/Hacking. The capitalisation being inspired by the Free Desktop common User Directories style, e.g. Music, Desktop, and so on.

And then Go, which is inflexible in where you place your code, requires you to specify a $GOPATH to a directory containing src/, pkg/ and /bin. I initially misunderstood this to be some useless path for internal use by Go tools and not needed by the user, so I put it in ~/.go where it wouldn’t bother me. It turns out that you actually keep all your source code there and use it every day. It’s so common for people to put their code in ~/go that starting with Go 1.8 this will be the default $GOPATH if you don’t specify one.

On the other hand, grouping your files by what language they were written in is silly. Imagine ~/Work/Java Projects/ ~/Work/PHP Projects/ instead of grouping them sensibly based on what they’re for instead of how they’re written. Or imagine /bin/c/ls /bin/bash/update.sh /bin/go/docker

From the “How to Write Go Code” document:

Another common setup is to set GOPATH=$HOME.

And so that’s what I did.

I moved everything from ~/go to ~ and I moved my own scripts and stuff from ~/.local/bin to ~/bin, symlinking ~/bin back to ~/.local/bin so that anything expecting it there can find it.

Go requires you to organise your programs under src/ by host and then by author (raising some new issues, like what if it’s unhosted) which seems like a reasonable way of organising lots of things, conveniently also keeping work separate from free-time open-source stuff on GitHub. And since it’s inflexible about it, I might as well make lemonade from lemons and use it for everything else.

I’ve just scratched a 5 year itch and that’s where I am now. This seems neater than before, let’s see how it works!

Vim “fake fullscreen”: open split windows in a new tab

Since I use a lot of split windows in Vim, for example when exploring the git log or editing closely related files, a pattern I noticed is I often want to make one of the smaller windows full screen momentarily so I can read more at once without scrolling and then close it when I’m done. I made a really simple mapping to simulate this “full screen” idea:

:nnoremap <Leader>f :tabe %<CR>

This opens the current window’s buffer in a new tab (fake full screen 😁) and when I close it I’m back to tab one with my split windows.

To demonstrate, here’s a gif in which I inspect the git blame for a file, open a patch and then open it “full screen” in a new tab:

Vim fake fullscreen demo gif

Vim fake fullscreen demo gif

Browsing the git log isn’t the best example because fugitive’s blame window already has an O mapping which opens the patch in a tab instead of a split and the necessity for this would be clearer with bigger files like those I edit at work.

This is one of the few things I use tabs for since I’m mostly jumping through buffers. Hopefully it’s useful for you too!