Irreal

Just in case you aren’t tired of the editor wars, Ron Wills has a short post that compares the two editors. There’s a lot of that going around, of course, but I like Wills’ post because his conclusions are neatly congruent with mine.

Two main points:

• Many think of Emacs as being an editor with a Lisp extension language but Wills (and I) think that’s backwards. Emacs is actually a Lisp interpreter with a built-in editor as its font end.
• Arguing about which editor is better is silly because they are two different types of applications with different intended uses. Vi is meant to be a lightweight editor that’s fast to load and easy to use. Emacs is, of course, also an editor but that’s only one of its faces. Emacs is a platform for performing just about any function you can perform on a computer. Which editor you think is best depends on what you’re looking for.

Wills and I agree on that last point. Use whichever editor best fits with your workflow. They’re both great editors. And who knows, maybe your needs will change and you’ll try the other. Lots of us have been down that path. In both directions.

Konrad Hinsen has an interesting post positing that Emacs is one of the few pieces of malleable software extant in the modern software environment. To understand what that means, you should first read the definition of malleable that Hinsen links to. When I read it, I was struck by how similar it is to the GPL except that, like Emacs, malleable software should contain a built-in method of changing the software to your liking. The idea, as with the GPL is that users should be a able to adjust their software to fit their workflows.

Hinsen says that in the 70s and 80s, malleability was a common design goal but that only Emacs has any real traction today. His post considers why this is and contrasts Emacs with Smalltalk, another piece of software designed with malleability in mind. The difference, he says, is that Emacs is useful out of the box for the end user, while Smalltalk—which is, in some ways, more malleable than Emacs—is useful for developers but not much use at all for an end user.

Thinking of Emacs’ advantages in terms of malleability is a useful viewpoint. On the one hand, it’s really no different from what we always say but on the other, it gives us a framework for understanding why those advantages are advantages and matter so much.

Again, be sure to read the definition of malleability. You can’t really understand the post without it and it is, in some ways, the most interesting part of the post. This is a useful post if you want to understand what makes Emacs so special.

I did a double take when I saw this tweet:

I prefer small editors for programming like #emacs instead of fat and slow Java-IDEs.

That is so true: https://t.co/Ic8RljDOmn

— Daniel Gerlach (@gerlacdt) April 6, 2020

As everyone here knows, I’m all in on Emacs but I’ve seldom seen it described as “a small editor.” Emacs is many things but “small” isn’t one of them. I wondered why anyone would described it that way. I followed the link in the tweet and got the answer.

That answer is today’s red meat although for us Emacs true believers it seems more like an obvious truth.

Eamonn Sullivan has a post that describes Emacs as A Well-Honed Tool. If you’re an Emacs user, your immediate response is probably, “Well, yeah!” but Sullivan’s point is more than just Emacs is a great editor. There is, as he says, a reason he uses an editor that’s almost as old as he is.

Emacs has been around long enough that several generations of users have worked on sanding down the rough edges and making it an extraordinarily useful tool. But, of course, the real story is that you can make Emacs into whatever you want: you can add new functionality or completely rewrite existing functionality because Emacs is written almost entirely in its own extension language.

Sullivan is an interesting case study because he has had two careers: in journalism and as a programmer. That gives him a foot in both Emacs user camps. He has used it as someone with a traditional liberal arts job and as someone with a program development job. That means he has probably explored more of Emacs functionality than most of us working in only one of those environments.

A subplot of the post is that he wrote a bit of code that largely automates the mechanics of making a blog post. The code is, he says, not particularly sophisticated and just bombs out if there’s an error but it was quick to write and solved a problem he was having. He expects that the code will evolve and get better but in the mean time, that problem is solved.

This is the type of thing I—and I’m sure most of you—are always doing: we’re performing some boring, mechanical task for the \(n^{\text{th}}\) time and suddenly realize we could write a bit of Elisp to do it with a couple of keystrokes. We may or may not evolve the code but that boring, mechanical task has been banished from our workflow.

Emacs really is a well-honed tool.

If you follow the Emacs scene, one of the questions you see all the time is how to configure Emacs as a Python IDE. Emacs, of course, offers rudimentary support for Python but that consists mostly of syntax highlighting and indentation. Fortunately, there’s elpy, an Emacs package that brings a more complete Python IDE to Emacs.

Sean Wade Jon Fincher has a nice post that serves as a mini-tutorial on how to install and configure Emacs and elpy to provide an excellent Python development environment. He begins with a short introduction that links to Xah Lee’s instructions for installing Emacs and covers just a little bit about how to use Emacs. He recommends doing Emacs’s built-in tutorial to learn the basics.

After the introduction, Wade walks you through making a minimum configuration. Experienced Emacsers may or may not like his configuration but it is an appropriate for a N00bs who can tweak things to their liking when they get a little more experience.

The meat of the post discusses how to install and use elpy. Read the post for the details but it doesn’t seem very complicated. Then Wade talks about adding things like flycheck, the black code reformatter, integration with Jupyter Notebooks, and, finally, Ipython.

Wade concludes the tutorial with a discussion of support for testing, debugging, and version control. The result is a very nice Python IDE built into Emacs. That can be important because, as Wade says, the average developer will be writing in several computer languages, perhaps using a markup language like Markdown or Org, writing Shell scripts, and probably many other editing chores. That developer can be much more efficient if he uses and masters a single editor for all those tasks rather than depending on bespoke editors for each language or chore.

Even if you use Python only occasionally, it’s worthwhile having a REPL and proper language support so Wade’s post is definitely worth your while.

UPDATE [2020-04-06 Mon 13:53]: Added link to Wade’s post.

UPDATE 2 [2020-04-14 Tue 13:28]: Sacha wrote to say that Wade’s article appears to be a reposting of one by Jon Fincher. A bit later Dan Bader wrote that Sacha is correct and that apparently the site (morioh) is making a habit of such things. If you follow the link that Sacha and Bader provide, you can see that it is, in fact, the same post. How is this right or even legal?

UPDATE 3 [2020-04-14 Tue 15:10]: I’ve removed the link to Wade’s post so as not to reward bad behavior with a link. The post itself is well worth reading so go read Fincher’s original.