The Craft of Text Editing: Emacs for the Modern World (1999)
finseth.comThis might be more accurately titled "The Craft of Making Text Editors." It is mostly not about Emacs, rather about more abstract ideas around user interface (see the quaint Joystick section) and text editing:
> This model is the basic two-dimensional form. Instead of editing a line, the user is editing in a quarter-plane, with the origin usually in the upper-left corner. Conceptually, the user can move freely in the two-dimensional quadrant. In practice, the editor usually only stores the non-blank portions, as storing an infinite-quadrant's worth of data can be prohibitively expensive. Some systems may impose fixed upper bounds on the width or length of the quadrant.
Sure, that's fine I guess, but this doesn't help me understand how to use or program Emacs. And most of the code is in C, not Elisp.
As I recall, most of the work Craig did on this book was from the early-to-mid 1980s, before GNU Emacs (or at least before it became popular). In fact, I believe it grew out of his B.S. thesis, written in 1980.
Anyway, not every programmable editor is programmed in Elisp.
After having used Emacs exclusively at work for a few years, I am in the process of switching to Sublime Text full time. ST delivers solidly on the excellent concepts that Emacs helped pioneer, including multiple cursors and using generic text buffers for every task. Plus it made the smart move of making ido-mode built-in (and improving its algorithm greatly in my experience).
The core concept of emacs, for me, is Lisp; that it's always there, an M-x eval-region away in any buffer, that creating new commands and altering existing commands is utterly trivial. I wouldn't give that up when moving to another editor.
I find helm much better than ido for most purposes. I couldn't live without helm-git-grep - it's how I navigate everything. I even add all my installed gems to a git repo just so I can use helm-git-grep easily when browsing / debugging 3rd party code.
I've gone through maybe 6 editors and IDEs in the last 20 years. I wish I'd started using Emacs 15 years ago instead of 15 months; I'd have wasted less time configuring keystrokes, and be more cumulatively productive.
The more obscure languages you use through, the more the only good support you'll find is with emacs compared to ST. See ocaml, fsharp, haskell, clojure, prolog, scala etc... But for html, CSS, js, ruby, ST is pretty good
What is a text buffer? I use Sublime exclusively and I never "got" emacs and I just assumed it had something to do with me not knowing what text buffers are and where to access them in emacs.
Emacs has a bunch of jargon that takes some getting used to.
A buffer is a file opened in the editor. The cursor is called the point, the text selection is called the region and is the text between mark and point. You open files by "finding" them. A pane in the editor is called a window.
Cut is called kill, paste is called yank, and there is no single simple jargon for copy - it's killing without deleting the text.
A buffer doesn't have to correspond to a file, e.g. "built-in" stuff like Messages or Help or scratch. I often "C-x b asdlkfj RET" to create a new "scratch" buffer for quickly jotting down something or transforming something. I can of course save that buffer to file, or I can just kill it.
When coding elisp, you often use the (with-temp-buffer …) macro to do more or less the same thing :-)
Also, several buffers can correspond to one file: "C-x 4 c" runs clone-indirect-buffer-other-window which creates two views on one and the same file. This is not the same as splitting the window: The two buffers can each have their own, different narrowings applied. Say you have two functions defined in one file, they're almost the same, so you want to compare them. Now, clone the buffer, narrow the first buffer to the first function, the second to the second, and now you can run ediff on the two buffers :-) Or you can even open the same file in different major modes at the same time …
I read this book in college and was captivated. Not terribly long, but fascinating for learning how the insides of our tools work (or could work better).