How I started using Emacs

As a former engineering student and now human-computer interaction researcher, I spend much of my time processing various forms of text. This resulted in me using many different programs to edit various kinds of text. OneNote was where I kept notes for years, until Joplin filled in the gap for a while after I switched to Linux, Eclipse was what I used as an integrated development environment for C/C++ and Java during classes and at work, TeXstudio was how I wrote LaTeX for typesetting assignments and the system’s default notepad application handled the rest. None of that was unusable, but it never felt quite right either. The problem was that all of these tools were doing some version of the same thing, yet each one came with its own interface and assumptions about the proper workflow. What I wanted was a single application that could cover all of those cases and still be flexible enough to fit me instead of forcing me to fit it.

My first encounter with Emacs

I ran into Emacs while I was looking for a source-code editor that supported multiple programming and markup languages. The reason for this was that I felt that the Eclipse interface was too slow and cumbersome for smaller software projects. I would also frequently find myself referring to and editing my programming notes while writing code, and I wanted a tool that was equally suited for writing prose as it was for writing code. GNU Emacs describes itself as an extensible, customizable, self-documenting editor, which immediately caught my interest. It looked like a system that multi-purpose Swiss Army knife that I had been wanting all along.

I opened my system’s software manager, found Emacs, and installed it without much hesitation. I tried it for a day or two, after which I dismissed it almost completely. The user interface looked outdated, the keyboard shortcuts made little sense to me and the defaults felt alien in a way that was hard to ignore. I remember being genuinely irritated that basic actions like cut and paste, which are mapped to Ctrl+w and Ctrl+y, rather than the usual Ctrl+x and Ctrl+v, were not what I instinctively expected. At that point, it would have been easy to come to the conclusion that Emacs was not for me.

I tried a few other alternatives, such as the now discontinued Atom text editor, but they all seemed to be missing something. Although many modern text editors have plugins to add extra functionality, these always felt like a bundle of random parts mashed together rather than forming a single integrated whole. Typically, each plugin is written against the application programming interface (API) provided by the editor, which exposes only a limited subset of the editor’s internal behaviour. When something breaks or you need functionality that has not been anticipated by the existing plugin architecture, there is often no straightforward way to fix or implement it yourself.

Perhaps I had been too harsh on Emacs; after all, one should not judge a book by its cover. So I decided to give it a second chance and learn how it was intended to be used. I went through the well-written Emacs manual and guided tour as well as made use of the help system designed to teach users interactively from within the editor itself. Once I understood the historical context in which Emacs was developed (the first public release was in 1985), many of the design decisions that had initially seemed strange began to make sense.

Coming back to Emacs

What eventually convinced me to stick with Emacs was that it approaches extensibility very differently. Most of the editor is written in Emacs Lisp, with a very small core written in C, meaning that the same language used to write extensions is also used to implement much of the editor itself. Emacs Lisp can also be used in the user’s initialization file. As a result, there is far less distinction between configuration, extensions and the editor’s own source code. Almost everything is inspectable and redefinable at runtime, meaning that you can make changes to the editor as you are using it. If you don’t like something in Emacs, you can change it!

This came in handy more often than I expected, because many problems only require a small amount of custom behaviour rather than an entire application or plugin. For a period of time, I worked as a tutor teaching programming to younger students. The company I worked for used a block-based programming environment similar to Scratch, where functionality was organized into colour-coded categories for graphics, movement, sound and so on. One difficulty students frequently encountered was locating the correct category for a particular block mentioned in the course material.

After finishing the lesson instructions, I wrote a few lines of Emacs Lisp that automatically highlighted block names in the document using the same colours as the corresponding categories in the programming environment. The change took less than an hour to implement, including the time the time spent reading documentation for Emacs’s highlighting system, yet it made the instructions noticeably easier for students to follow. One colleague was so impressed with the system, they wanted to know which text editor I was using so they could try it out themselves.

But can it do X?

You would be surprised how much of what we do on a computer can be achieved using plain text with a bit of structure that is read and modified in different contexts. Once you start thinking in those terms, Emacs begins to feel less like a text editor and more like a unified environment for interacting with text in all its forms. It includes built-in modes for many of these tasks: email can be handled through Gnus, IRC through ERC, file management through Dired, remote file system access through TRAMP, transparent editing of encrypted files through EasyPG Assistant, browsing documentation through WoMan and Info, shell interaction through Shell Mode, Term Mode and Eshell, numeric and symbolic calculation through Calc and much more. For programming work, Emacs provides a large collection of major modes for different languages, many of which integrate with the Language Server Protocol via Eglot.

Many software projects also ship Emacs integration as part of their own code base. For example, the computer algebra system Maxima has imaxima to allow symbolic computation results to be rendered directly inside Emacs buffers, the personal finance tool Ledger has ledger-mode, the password manager Password Store has password-store.el and the build system CMake has cmake-mode.el for syntax highlighting and indentation support of CMakeLists.txt and .cmake files. Historically, even Git once maintained an Emacs mode directly in its own repository, although this has been deprecated in favour of other Emacs packages.

If this is not enough, there is also a large ecosystem of packages available through GNU ELPA, NonGNU ELPA, MELPA and various independent repositories. This means that if you encounter functionality in another editor or application, there is a high chance that is already an Emacs package out there that does it. For example, Magit provides one of the most complete third-party interfaces to Git, AUCTeX is an excellent environment for authoring LaTeX, and there is indeed also Markdown mode. I never actually ended up storing my notes in Markdown, however, since Org mode was simply a better fit.

At some point, I did also learn how to use Vi, as I was working with a few Unix-like systems where it was the only text editor available. I found the modal editing paradigm and the concept of a compositional text-manipulation language to be surprisingly efficient once I had adjusted to it. I was, therefore, delighted to learn that Emacs includes Viper, which offers a fairly complete Vi interface that comes with and integrates well with the rest of Emacs. An external package Evil implements the additional features that Vim introduces on top of Vi, and together with evil-collection it extends modal keybindings across many other Emacs modes. Aaron Bieber gave a nice talk about some of the benefits of Emacs and Evil for Vim users.

Conclusion

If you often work with text and have not yet given Emacs a shot, or you tried it once but could not quite wrap your head around it, it is worth giving it a serious look. You do not need to learn Emacs Lisp straight away to make Emacs work for you, since much can be achieved simply through the graphical user interface. Do not be afraid to take advantage of the tool bar and menu bar to discover common functions as well as the built-in customization interface to tweak various settings according to your preferences. If the keyboard shortcuts are something that bothers you, as they did for me initially, you can activate CUA Mode from the Options menu that will allow you to use the familiar shortcuts for undo, copy, cut and paste instead.

There is also a large and active community around Emacs that can be helpful when you get stuck or want to go further. You can join the discussions on the mailing list and newsgroup, watch the Emacs Rocks screencast series to learn about various features or even take part in the annual conference dedicated to Emacs.

After having been a user Emacs for a number of years, it is hard to justify going back to a fragmented setup or use any other text editor. Thankfully, it is fairly certain that Emacs will be around for a long time to come.

Updated 2026-06-12 20:22:35 UTC. Built 2026-06-12 20:31:00 UTC.
This page is available under Creative Commons Attribution-ShareAlike 4.0 International.
Copyright © 2026 Jordan Schneider <jordanschn@jordanschn.com>.