RMS Does Not See the Future of Emacs

RMS Does Not See the Future of Emacs

27 Nov 2020
Emacs

I am an avid Emacs user. I’m using it right now to compose this post. I use it every single day for everything from work to school to personal notes. Most of my activity on GitHub comes from me tweaking little things in my configuration files. I now have an editor that perfectly fits my hands. Emacs is a big part of my life.

I’m afraid it’s dying.

Richard Stallman, one of the principle creators of Emacs and the head of the GNU Project, has made several choice in the past several months that I consider to be detrimental to the Emacs community and harmful for Emacs’ further growth. RMS doesn’t seem to care that much about making Emacs appealing to new users, and I think this is a mistake. Emacs derives its strength from being uniquely customizable and extensible; the more people we get using Emacs, the more good extensions, packages, tutorials, etc. will be available for Emacs. Some of the growth-hostile things include:

  • Shutting down suggestions for making Emacs start with a sensible set of defaults that would make it significantly easier for beginners to get started1
  • Purging links to the most popular (and most useful!) Emacs package repositories, Melpa and Marmalade, just because they might contain links to sites with non-free Javascript2
  • Ignoring community-driven development and exercising veto rule in cases where I personally think it was unwarranted3

I can appreciate strong leadership; I think for creating most things, having a single leader drive the development of a product gives it focus and direction that otherwise might kill it off. (I think Python is a good example of this at work.) In this case with Emacs, however, I think RMS is badly out of touch and should focus on what we as a community can do to make Emacs more robust so that future generations of programmers will have a strong motivation to use Emacs—a desire to run free software motivates precious few people in their selection of their tools. We should make it more appealing for its features and performance as well.

Some areas where Emacs stands to improve are:

  • Beginner-friendliness The default Emacs theme looks awful. No computer user used to the comforts of macOS or Windows would want to go near that ugly beast. It should have a pretty-looking theme by default. One idea would be to make it so that a new user can select some pre-built themes.
  • Performance There are some exciting things happening with gccemacs on this front. I’m not running that right now, as compiling Emacs master on macOS is a little persnickety. Improving its rendering engine would help too. I recognize that that is a big undertaking, and unfortunately I have little to offer in this regard.
  • Ease of contribution Why not host Emacs development on a self-hosted GitLab instance? Or use some other issue tracker? I understand that there are some advantages for mailing lists, but the set of programmers who are a.) familiar with that work flow, and b.) prefer it, is dwindling. An issue/PR-style flow makes a lot more sense for most developers, and I think it would go a long way to enriching community involvement in Emacs’ core development.

These are just my thoughts, and will likely evolve over time. Unfortunately I cannot devote as much time as I would like to improving Emacs, though I do enjoy learning to write packages when I have the time.

Good luck, all you Emacs maintainers out there. You’re heroes.

Mastodon