I recently tried out a new development environment for my Python development, and noticed an unexpected convergence in the designs of the two tools.
I’ve been a long-time Emacs user. I periodically get a desire to try something new, something less old-school, just to see whether there are advantages. There always are advantages, of course — but often significant disadvantages as well, which often keep me coming back to my comfort zone.
My most recent excursion was to try Microsoft’s VS Code.
This is handily cross-platform, being built in Javascript on top of Electron. It’s got a lot of nice features: a tree view of the project in the left-hand pane, syntax colouring, code style linting, integrated debugging and unit test running, integrated connection to git, and so on. Looking a little closer there are all sorts of status markers around the code and in the ribbons at the bottom of panes and the window overall to show status that might be important.
But it’s so slow. That’s a feature of VS Code, not of Electron (as I first suspected), because other Electron-based editors like Atom aren’t as slow. And my development box isn’t the latest, but it also isn’t that old.
So I reverted to Emacs, but upgraded it a little to more modern standards. Specifically, I installed the elpy Python IDE, with assorted other packages suggested by various sites. The result is this:
Now for anyone who’s used Emacs for a while, it’s definitely still
Emacs — not least with the convoluted keystrokes and infinite
customisation you either love or hate. But it’s striking how similar
the two IDEs now are, and striking how VS Code has inherited some
ideas from Emacs: resizeable panes, modelines in the ribbon, markers
in pane gutters, and so forth — things that Emacs-based applications
have had for years, which have now migrated into “the mainstream”.
Both the feature sets and the visuals of the two systems are very
similar indeed. Both are entirely cross-platform and extensible. For
VS Code you write extensions in Javascript; for Emacs you write them
in Lisp; and that’s about it. And Emacs is a lot faster on my
set-up. There are some limitations — I’ve yet to get the hang of using pdb
as a debugger, for example, especially for modules
and from within tests — but the functionality is really quite comparable.
I think it’s safe to say there’s been cross-fertilisation between VS Code (and other IDEs) and Emacs over the years. A lot of the developers of the former quite possibly used the latter. But I strongly suspect that most of the traffic has gone from Emacs to the other systems: the similarities are just too great to be accidental. It’s interesting to think that a system that emerged at the dawn of the free-software movement has had — and is still having — such an influence on modern development tools. And I’m happily back in my comfort zone.