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!

grml zsh inPlaceMkdirs

I keep forgetting this, but it’s really useful when working in the command line so I’m writing it down now. I use the grml zsh configuration in my shell and it has several very good features; a cool one I’d use more often if I could remember the shortcut is “in-place mkdir”. The key sequence is:

Ctrl-X, Shift-M

That’s Ctrl and x, followed by an uppercase M.

Here’s an example use case: Imagine you’re writing a command to do something with a very long path, like moving a file deep into a source tree

mv File.java src/something/very/long/

except half-way in your realise some of the directories in that path don’t exist. No problem! Usually you’d have to cancel that command, create the missing directories and then type it again. Now you can just type Ctrl-X, Shift-M, the directories are created and you can just press enter to use them. Much less annoying! This can even work for different directories in the same command; move the cursor to the directory you need and zsh will create that one!

For other useful shortcuts, see the reference card.

Automatically Pop Up Steam Key

Now that I’ve got steam, I get to be constantly pestered by e-mails sending me keys with which to identify that I am myself. To save a few steps in this annoying, repetitive process I wrote a tiny bash script which finds the key in an e-mail from steam and uses zenity to pop it up on my screen, then added a filter in Evolution Mail to mark these “steam verification” messages as read and pipe them to the pop-up script. This allows me to copy the key with a double-click and paste it into steam with a middle-click, without having to poke around in my mail client for the e-mail and the place where the key is mentioned in it.

In the hope that it saves someone else from this irksomeness, here’s the code for the script:

/sinisterstuf/5795214
#/bin/bash
 
# Displays a pop-up showing a Steam activation key piped to it by a MUA.
# In the e-mail the steam key is wrapped in <h2> tags
# Author: Siôn Le Roux <sinisterstuf@gmail.com>
 
# read e-mail from pipe
while read -r line; do
    # find <h2>
    buffer=$(echo $line | grep 'h2')
    if [[ ! -z $buffer ]]; then
        #strip surrounding <h2> tags
        steamkey=$(echo $buffer | sed -e 's/<\/\?h2>//g')
    fi
done
 
# display the steam code in a pop-up
zenity --info --title="Steam Key" \
    --window-icon="/usr/share/pixmaps/steam.png" \
    --text="<tt><big><b>$steamkey</b></big></tt>"

Packaged Tomboy add-ins for Arch Linux

The wiki-like note taking application, Tomboy, maintains a list of user-written add-ins on its website, almost none of which were available in the Arch Linux repositories. Recently I learnt how packages are created for Arch Linux and read up on the standards, so I ‘adopted’ an ownerless add-in package from the Arch Linux User Repository and packaged 6 more.

Finally, I created a meta-package called tomboy-extras which contains nothing but depends on all the working Tomboy add-ins (tested on my laptop) in the AUR, to easily install all add-ins at once. I created a gist on GitHub for each package’s build script and made a repository containing the meta-package’s PKGBUILD file and each gist as a git sub-module named after the package name. The README file in tomboy-extras’ git repository contains links to the gists for the add-ins’ PKGBUILDs so that they can be found easily.

So, if you would like to contribute to one of them, feel free to fork the relevant gist, or leave a comment there, and if you would like to contribute to tomboy-extras itself or have an add-in included, just fork tomboy-extras and send a pull request; I’ll probably be adding more add-ins to it myself already. Also, if you do use any of these packages, please give them a vote on AUR so that we can see how many people use them. If they’re popular, they may be included in the official repositories, who knows!

Running Sparkup Vim Plug-in on Arch Linux

The sparkup plugin for vim lets you write HTML markup faster by Zen Coding, in which you write short code, resembling CSS selectors, which is then expanded to HTML by the editor. For example, writing

div#nav>ul#menu>li.item*3

would give you:

<div id="nav">
    <ul id="menu">
        <li class="item"></li>
        <li class="item"></li>
        <li class="item"></li>
    </ul>
</div>

This is obviously extremely useful, as it saves a lot of typing. However, I encountered a bit of trouble using this plugin on my laptop, which runs on Arch Linux. It’s easily solved though. Continue reading

Steam available in Arch Linux repositories

This news is at least a few days old by now, but it seems the official Steam client for GNU/Linux is now out of Beta and ready for use! Ubuntu users could already download the deb package from the steam website. However, if you’re an Arch Linux user, like me, then you’ll find that since the 26th of February, the steam client is already in the official Arch repositories and can be installed with a simple:

# pacman -S steam

Of course as soon as it’s installed it’s time for Steam to start its slow, perpetual update process, but except for that I think this is fantastic!

Free Software Day tomorrow

If Pockey Lam hadn’t pointed it out I probably wouldn’t have known it was Software Freedom tomorrow. Better than last year though, when I only found out after it had happened. Software Freedom is important to me —most of this blog is related to it— and I’d really like Namibia to participate in this event, especially the Polytechnic of Namibia where I study, as it’s one of the few universities on the African continent mirroring Free Software.

In this effort I’ve written a post on the PoNLUG site and sent some emails in an attempt to get people excited about organising something for an event this weekend or Monday, because I can’t do something like this by myself. I realise it’s probably a bit late to try to get something big going at this point but hopefully we can do something and next year the PoNLUG will be prepared for Software Freedom Day!

Icedove and Enigmail

A tip for any Debian user trying to get PGP to work in Icedove, Debian’s re-branded version of the Thunderbird Mail client: All the tutorials and forums on the internet telling you to install Enigmail from Thunderbird’s Add-on menu won’t work. It’s not there. Enigmail isn’t compatible with your version of Thunderbird, which is… Icedove. The solution is simple but not obvious; Enigmail needs to be installed from the package manager, a simple

aptitude install enigmail

should do the trick! 😉