Status Update on Emacs

April 10, 2023 3 minutes

I’ve used Emacs for years, and it’s not easy to get rid of this archaic (what?) editor. Although it helped me do my job better, my setup was not as stable as in the editor. When I started working as a web developer, I was installing all the project requirements on the local machine, even though I was not using virtual environments. Emacs was good enough to make development possible.

Then, I started using tools like vagrant, docker, and virtual environments that made it easy to install the project but difficult to use Emacs because I needed to configure the editor to find the right Python interpreter, Node version, etc. Having the language server protocols (LSP) was a great help, but I still had to create a virtual environment for each project.

Then I switched to remote development; I had a remote server to access the same development environment from all my devices. I was using a good terminal emulator like WezTerm, connecting to the server using MOSH or Eternal Terminal, and running Emacs on the server remotely. This has never been as comfortable as working locally.

In each case where my setup has changed, I have updated Emacs and reconfigured it for the new environment. If you take a look at my Emacs configuration, you will see that I’m using vanilla Emacs with the minimum configuration, and I try to use built-in packages as much as possible. But now I’m at a new crossroads because I started using AI tools actively and am getting bored waiting for the tools to support my editor. I’m looking at the GitHub Copilot, and even they don’t have a plan to support Emacs officially. You can say that it’s a tactic to force them to use their own editors or that they don’t have time to support all the editors. Maybe it’s better to help the community take initiative for preparing the extension. But anyway, that’s not fair or helpful for maintaining the diversity of the editors.

Probably it’s not easy to change my habits quickly, but I plan to use VSCode for a while and see what I’m missing. I know that VSCode has good remote development tools and official GitHub Copilot support. During this period, I will update Emacs to have the same features as VSCode and try to use it again.

For now, I want to compare the two editors for the extensions I’m using in Emacs. These extensions are mostly not needed on VSCode because they are built-in features:

  • company, company-prescient: autocomplete extension.
  • ctrlf: better search and replace.
  • deadgrep: ripgrep integration for Emacs. I’m using the built-in search and find commands on VSCode.
  • diff-hl: shows git diff in the fringe.
  • eglot: LSP client.
  • find-file-in-project: Helpful for finding a file in a project.
  • multiple-cursors: Another extension for editing multiple lines at once.
  • expand-region: Not easy to do this on VSCode (CTRL+CMD+SHIFT+Left what the hell?) but yes it’s a built-in feature.
  • magit: Git app for Emacs. I don’t think that I can find an equivalent in any editor. Don’t suggest me GitLens, please.
  • minions: Hides minor modes on Emacs mode line. Not necessary on VSCode.
  • modus-themes: My favorite theme for Emacs. I’m using the GitHub theme on VSCode.
  • puni: Structured editing tool for Emacs. Not sure if I can find an equivalent on VSCode.
  • vertico, vertico-prescient: Similar to CTRL|CMD+SHIFT+P or CTRL|CMD+P on VSCode.
  • tree-sitter, tree-sitter-langs: Not sure if VSCode needs this extension, but it’s a great synax parsing library for Emacs.
  • unfill: For unfilling paragraphs with a shortcut.

My Emacs configuration is available on GitHub.