Wandering Thoughts archives

Getting gocode based autocompletion working for Go in GNU Emacs

The existing guides and documentation for this are terrible and incomplete for someone who is not already experienced with GNU Emacs Lisp packages (which describes me), so here is what worked for me. I'm going to assume that your $GOPATH is $HOME/go and that $GOPATH/bin is on your $PATH.

• get gocode itself:

  go get github.com/nsf/gocode
  

  To work in GNU Emacs, gocode needs an auto-completion package; it recommends auto-complete, so that's what I decided to use. If you have that already you're done, but I didn't. At this point you might be tempted to go to the auto-complete website and try to follow directions from there, but you actually don't want to do this because there's an easier way to install it.

• The easiest way to install auto-complete and its prerequisites is through MELPA, which is an additional package repo for Emacs Lisp packages on top of the default ELPA. To enable MELPA, you need to add a stanza to your .emacs following its getting started guide, generally:

  (require 'package)
  (add-to-list 'package-archives
    '("melpa" . "https://melpa.org/packages/"))
  (package-initialize)
  

• make sure you have a $HOME/.emacs.d directory. You probably do.

• (re)start Emacs and run M-x list-packages. Navigate to auto-complete and get it installed. If you're running GNU Emacs in X, you can just click on its name and then on the [Install] button; if you're running in a terminal window, navigating to each thing and then hitting Return on it does the same. This will install auto-complete and its prerequisite package popup, the latter of which is not mentioned on the auto-complete site.

  It's possible to install auto-complete manually, directly from the site or more accurately from the github repo's release page. Do it from MELPA instead; it's easier and less annoying. If you install manually you'll have to use MELPA to install popup itself.

• Set up the .emacs stanza for gocode:

  (add-to-list 'load-path "~/go/src/github.com/nsf/gocode/emacs")
  (require 'go-autocomplete)
  (require 'auto-complete-config)
  (ac-config-default)
  

  This deliberately uses the go-autocomplete.el from gocode's Go package (and uses it in place), instead of one you might get through eg MELPA. I like this because it means that if (and when) I update gocode, I automatically get the correct and latest version of its Emacs Lisp as well.

Restarting GNU Emacs should then get you autocompletion when writing Go code. You may or may not like how it works and want to keep it; I haven't made up my mind yet. Its usage in X appears to be pretty intuitive but I haven't fully sorted out how it works in text mode (the major way seems to be hitting TAB to cycle through possible auto-completions it offers you).

(Plenty of people seem to like it, though, and I decided I wanted to play with the feature since I've never used a smart IDE-like environment before.)

See also Package management in Emacs: The Good, the Bad, and the Ugly and Emacs: How to Install Packages Using ELPA, MELPA, Marmalade. There are probably other resources too; my Emacs inexperience is showing here.

(As usual, I've written this because if I ever need it again I'll hate myself for not having written it down, especially since the directions here are the result of a whole bunch of missteps and earlier inferior attempts. The whole messy situation led to a Twitter rant.)

Why we wind up deleting user accounts

In a comment on my entry on optimizing finding unowned files, Paul Tötterman asked a good question:

I'm surprised that you actually remove users instead of just disabling them. Care to expand on that?

At one level, the answer is that we remove users when account sponsors tell us to. How our account management works is that (almost) every user account is sponsored by some professor; if the account's sponsor removes that sponsorship, we delete the account (unless the person can find another sponsor). Professors sponsor their graduate students, of course, but they also sponsor all sorts of other people; postdocs, undergraduate students who are working on projects, visitors, and so on. There's no requirement to withdraw sponsorship of old accounts and it's customary to not do so, but people can do so and sometimes do.

(For instance, we have no policy that graduated grad students lose their accounts or have them disabled. Generally they don't and many of them live on for substantial amounts of time.)

But that's not the real answer, because I've glossed over what prompts sponsors to take action. Very few professors bother to regularly go over the accounts they're sponsoring and decide to drop some. Instead there tend to be two underlying causes. The first cause is that the professor wants to reclaim the disk space used by the account because the other option is buying more disk space and they'd rather not. The second cause is that we've noticed some problem with the account (for example, email to it bounces) and the account sponsor decides that removing it is the simplest way for them to resolve the situation. This usually doesn't happen for recent accounts; instead it tends to happen to the accounts of people who left years ago.

(Account sponsors are 'responsible' for accounts that they sponsor and get asked questions about the account if there are problems with it.)

Our current approach to account removal is a multi-stage process, but it does eventually result in the login getting deleted (and sometimes that happens sooner rather than later if the sponsor in question says 'no, really, remove it now').