Jupyter is great. Yet, I find myself missing all the little tweaks I made to Emacs whenever I have Jupyter open in a browser. The obvious solution is to have Jupyter in Emacs. One solution is EIN, the Emacs IPython Notebook. However, I had a mixed experience with it: it would often hang and eat up memory (I never bothered to try to debug this behaviour). A neat alternative, for me, is emacs-jupyter. Here’s my setup.
My research often has a computational component which means logging into one of my servers, kicking off a long running computation, waiting a few days and recovering the output. Here’s how I, inspired by Filippo Valsorda’s post, addressed some of the pain points with this sort thing.
Like many other people, I write, receive and loath a lot of email. Writing it goes something like this:
- Create a new draft,
- figure out the right address to put into the
- write “Hi <first name>”,
- write the actual message,
- attach the correct file (if any),
- append “Cheers, Martin”.
Also, a lot of email is repetitive and boring but necessary, such as asking seminar speakers for their titles and abstracts, giving people advise on how to claim reimbursement when they visit Royal Holloway, responding to requests of people who’d like to pursue a PhD.
Here is my attempt to semi-automate some of the boring steps in Emacs.
Academics write. Academics in my field also tend to write in groups of two to five people. Back in the dark days — which I’m told are not over for many researchers — this used to involve mailing LaTeX sources around, forgetting to attach the right file, “I take the editing token for file.tex” e-mails, questions like “Where is the most recent version of the draft?” and so on. In some cases, I’m told authors actually sat down together and did grammar fixes in a meeting. In a word, it was horrible.
Judging from anecdotal evidence, it is not that bad anymore. Many people now use some sort of revision control to write their papers, with either Subversion or Git being the tool of choice. However, my impression is that we don’t use the tools available to us to the extent we should. So let me try to make my case for a better practice of collaborative writing for (crypto) academics.
A while back I described my (then current) setup to develop C code with Emacs. The other programming language I tend to spend a lot of time with is Python, specifically Sage’s Python. Here’s my Emacs setup for writing Sage code. For starters, it makes sense to highlight indentation in Python.
(use-package highlight-indentation :ensure t)
- M-. Goto definition for thing at point.
- M-, Switch to buffer of most recent marker.
- M-? Show documentation for context at point.
- M-r Show usage for thing at point.
(use-package anaconda-mode :ensure t :diminish anaconda-mode :config (bind-key "M-," #'anaconda-nav-pop-marker anaconda-mode-map))
Recently I spent some time customising my Emacs config again. Playing around with different ways of improving your productivity by adjusting Emacs is a great way of loosing any and all productivity you might have had. It is such a fun way of wasting your time, there’s even a little scene around just that activity. This can take quite elaborate forms with people posting their Emacs
init.el configuration files in literal programming style based on org-mode‘s org-babel. This is more useful than it might sound, e.g. I stole a lot from Sacha’s config.
I also recently spent a bit more time again writing C99 code making many calls to FLINT – Fast Library for Number Theory. The FLINT coding style requires that pretty much each function should have its own file which I am sure is great for something. However, for me it means that have I have to open a lot of files all over the FLINT library when I care about implementation details and not just definitions. Also, your vanilla Emacs setup won’t display those signatures when you try to write a call to those functions from your code or give you auto-completion for all functions starting with, say,
Alas, here is my current setup which rectifies most of my grievances.