An Interview with Mickey Petersen, author of Mastering Emacs

Source: GitHub

An interview with Mickey Petersen, author of Mastering Emacs

Who are you, and what do you do?

I'm Mickey Petersen. I live in London, UK.

I'm a professional software developer, and I have been programming since I was around 10 years old.  I did not have friends or family who knew much about computing, so I had to learn everything myself, from scratch.

How did you get interested in that in the first place?

I cut my teeth programming C in Turbo C for DOS and moved on to Delphi for Windows some years later, whilst at the same time trying to get a grip on this fairly new-fangled thing called Linux. Back then you had to go through all manner of hoops to even get it: I think I got mine from a CD that a friend of a family member had. It would've been far too large for my meagre 33.6k dialup modem connection to even attempt to download it from the web.

It was a Red Hat distro and I distinctly remember spending an eternity printing out the manual – as I would otherwise not be able to even *install* Linux, as I knew nothing about it – and then a long time figuring out how to install and use it. FVWM95 was the window manager, meant to look like Windows 95, and it was a great experience "running Linux" and using tools that would never work on DOS or Windows at the time. Back then Linux was the 'cool' thing and Windows and DOS.... not so much!

I tried programming C on Linux, and I remember trying Emacs back then. It had this funky green colour scheme; pretty sure it was a Red Hat X Resources thing at the time. But I could be wrong. Nevertheless, my flirtation with Emacs did not last. At the time it was just another tool in a succession of editors I experimented with. I probably settled on a graphical one that shipped with Red Hat as it had, you know, things like region selection and syntax highlighting enabled by default. Emacs could of course *do* both, but they weren't enabled by default back then.

Along the way I experimented with all manner of packages, window managers, and more. They took ages to compile, but back then – as a kid/teen – you had oodles of time, so it didn't really matter. But it laid the foundation for my interest in Linux and much more.

Many years later I would, during my time in uni, pick up Emacs. That time it stuck. I was a member of my university's computer science society, and the Dewey decimal tribunes who held court and sway in that society, were keen to let all and sundry know that Real Hackers Used Vim. Not Emacs; not ed(1), kate, or any other editor; just Vim. I never did buy into groupthink – and certainly not from someone scarcely older than myself – so I went with Emacs, as I'd at least played around with it many years before.

At the time I did not really know what you could, or could not, do with Emacs. I mostly navigated with arrow keys, a handful of key bindings, and the menu bar. I went with XEmacs, as it was generally ahead of GNU Emacs in the early noughties.  As my coursework in uni involved a never-ending succession of LaTeX and various common and obscure programming languages, Emacs was a great choice. It had syntax highlighting for almost any language you could think of, and although I did not know about some of the more obvious features (comint, shells, etc.) I at least had a tool capable of running on all major platforms and with a consistent experience.

XEmacs had its downsides, though. It was falling behind and had its own way of doing things that was not entirely compatible with GNU Emacs. I eventually moved to GNU Emacs when, I think, Emacs 22 came out.

At some point during my time with Emacs back then, a light bulb went on in my mind – something that I know now, having written and taught people Emacs for many years, is a frequent occurrence – that I finally understood enough about Emacs to not feel lost. I could look up commands and keys; install and edit code; and even write some elisp!

I'd begun experimenting with Org mode, so I started a file called blogideas.org (blogs were all the rage back then!)  to capture all the things I knew and I wish others did too. That would then morph into Mastering Emacs.

Since graduating uni, I've been a professional developer. I build bespoke software for clients around the world — with Emacs as my trusty editor, of course!

What resources would you recommend for people that are interested in what you do?

For programming? Gosh, there's too much. Back in the day it was actually really hard to learn programming as you'd need books, the web/internet, or know someone who knows a bit about it. Today, it's infinitely easier to get started — though I think it's equally hard sticking to it, and becoming proficient!

I found your work through Mastering Emacs, a phenomenal site – and book (written in Emacs, of course) – that helped me design my Emacs workflow (more so as a writer than a developer). Emacs can be intimidating for first-time users. Why should they choose it over another text editor?

Thank you! I'm glad you like both. That was exactly why I started the site.

Well, you're a writer using Emacs, and I think that is interesting.

I firmly believe that a significant proportion of Mastering Emacs readers are not professional "techies" (be it system administrators, developers, testers, etc.) but either tech-adjacent or work in fields where they are expected to have some technical proficiency in their field – a dab of Fortran or Python here, a pinch of LaTeX there – and use Emacs primarily as a tool to connect disparate areas of their work that other, non-Emacs users cannot easily mimic. Editing code is easy; there's myriad editors, including Emacs of course, that can do this. But there aren't many tools to track bibliography, your agenda, email, notes, and writing. But Emacs can easily do all of that, and much more.

Some Emacs users learn it because it's a "tax" they have to pay to work in certain academic circles or commercial environments where it's the only one available, or widely used. Something my cohort in University discovered when our lecturers would hand-wave away questions like "What should we use for editing Prolog?" with "Emacs."

So I think that people should learn Emacs if they want greater control – or freedom (also in the FOSS sense) – to mould their environment and tools to their liking. Not everyone does; if you dislike tinkering and tweaking, then Emacs is harder to sell. But to those of us who have had to use an application only to find that its keyboard shortcuts get in the way (or are missing altogether); or that one key that you use that does not work in some modal dialogues; or the frustration when you have to multi-task between umpteen tools – we find comfort in Emacs, because we are imbued with a tool capable of adapting itself to our needs. Emacs is a crucible.

What are some areas where Emacs could improve, either for longtime users or for newcomers?

Hm, this is a good question.

Emacs is written and designed for people who already know Emacs. That's not so great if you don't know Emacs; but it sure is if you do. Emacs opts to replace a low skill-ceiling (and anaemic key bindings and features) with a very high one (exceptionally powerful key bindings, programmability, etc.), because if you persevere then you'll eventually learn enough to benefit from an editor that does not hamstring its users.

But that simile applies to a range of things: no matter how many books, videos or power tools you buy, you won't become a master cabinet maker overnight. It takes skill and practice. It's just that we associate "text editor" with, well... notepad. Emacs is much more than just that.

Emacs is already much friendlier than it used to be. Better defaults; more sensible inclusions that ship with Emacs. Emacs 29 adds tree-sitter and Eglot, two tools of great import to coders, that should further reduce the friction for someone keen to experiment with Emacs without having to spend a weekend learning how to set it up.

The hardest thing for newcomers – and I say this as someone who did not think to do this myself as a newbie – is to read the manual. It's right there on the splash screen, or conveniently located in the help menu. But all too many "experts" recommend you hide the splash screen, and turn off the tool and menu bar. I fell victim to that advice when I was new also. It was terrible advice. Why hide something that helps you learn and explore?

Many suggest changing the key bindings or Emacs's unique vocabulary, but I think it's window dressing, and it won't alter the learning curve much, if at all.

So my suggestion is this: alter the tutorial (C-h t) so it's interactive, prettier, and more detailed. It should neatly segue into other areas important parts of Emacs. There's a wide range of users: prose writers; note takers; coders; command line hackers; etc. Emacs is more than capable of this interactivity, and yet the tutorial makes no use of it. Emacs should be a bit more firm in its advice to newbies.

What are some of the Emacs specific workflows that help you get your work done (packages, changes from defaults, etc.)?

For me it's the ability to program Emacs when I need to. I had to write some e-mail filters – sieves, as they're known – for an e-mail server. That was tedious as I had to test that they worked; what emails they'd affect (lest I screw up badly and ransack my emails); and then against particular e-mails to make sure the filter works properly for that particular e-mail.

I wrote a handful of lines of code that glues various parts of Emacs together to do this. I press a button and Emacs connects to the remote server with TRAMP and calls the program it needs to call, and then displays the result in an Emacs buffer.

So that's the most important one: adaptation to changing requirements.

I use mostly stock Emacs key bindings, with a handful of changes to make certain things more bearable. M-o instead of C-x o; C-x C-k to kill the current buffer; F1 opens M-x shell; and a handful of other minor things.

For productivity-related stuff I use Helm a lot for specific tasks. I can call up a Mastering Emacs customer using Helm and find their sales details. Great for when people forget their email or need to change something. It's a great completion framework. I also use IDO for files and buffers and Selectrum for general-purpose completion.

Besides Emacs, what tools & gear do you use (hardware, software, or anything else that comes to mind)?

I use a ZSA Moonlander Mark 1. It's one of those fancy 'mechanical' keyboards. It's quite nice. It's programmable and extensible, and it's more comfortable than normal keyboards. I used a MS Ergonomic keyboard for about 20 years and I'd literally wear them out in about 2 years.

I occasionally do some computer gaming. So I tend to overbuy every couple of years so I don't have to care about upgrading much for the next several years. So my primary workstation is an uber-high-specced desktop (that also doubles as a space heater) with a 39" ultrawide monitor. The monitor I love. I used to used dual monitors, but... eh. This is way better. One enormous Emacs frame that I can easily split into multiple windows.

Besides the tools, what habits & routines help you finish your work?

I rarely finish my work. Unless someone's paying me, that is!

I am a habitual starter-of-projects, finisher-of-few. Half-baked, half-inventions is how I generally term the stuff I do. I tend to build something out until I'm satisfied I've sated whatever silly intellectual curiosity I have, and then I drop it like a rock, as it's rarely perfect enough for me to release.

My projects folder is full of these things.

How do you relax or take a break?

I set my own working hours, as I generally work on my terms. For clients my work is a case of agreeing the scope of what needs doing, and then I get on with it. But it's unlikely to follow a 9-5 schedule, per se. So when I want a break, I get up and walk around. Living in London affords me the ability to do all manner of cultural stuff, if that is what I feel like.

I've realised the key to my happiness is small bouts of things that bring me joy: a cup of coffee; a nice walk; it's the little things. I also adore cooking and do it daily with my girlfriend. We both enjoy food and cooking.

Whose work inspires or motivates you, or that you admire?

Hm, you know, it's a good question. I self-motivate, I think, mostly. I know it's common for people to look upon the works of others for inspiration, and I think that is probably true of me as well. But it's more of an ethereal thing for me: it's a range of things – concepts, ideas – that drive me, and less so any particular person. So when I sit down and half-invent something, it's because of that.