#+Title DNW's GNU Emacs Configuration #+PROPERTY: header-args :tangle ./init.el Top-level TODOs: - Org-agenda and calendar/diary - Better org mode in general --- org-insert-link-global - Clean up prose on "Why Emacs" - BBDB - Mail - Debug/PR Eshell visual commands over TRAMP - Learn how to use compiling and debugging - Generalize system package installations to non-Arch package managers - Test eglot, consult-eglot, etc. - More extensive display-buffer-alist integration with edwina. - Fix bank stuff and get a ledger setup working. * Why Emacs? #+begin_verse ... Reason is clouding, Hearts are hardening, And the result is murder. This age is grave bound, Likewise its aging successors. Aging, all the while, descending Developing an even more insatiable thirst for chaos. Life among hyenas and asps under vultures That pick at the corpses of the fallen. And man will continue to suffer unto itself Until some stand to rally the fray by firm example. Chaos must succumb to order Lest these days be numbered. I cannot contribute to disarray. I simply cannot relate. Let this be my act of defiance. Let this by my refusal to fit in. Let this by my writ of misanthropy To a thankless world of men Who have perfected nothing. Save the art of accusation. ... --- /Scornful of The Motives And Virtue of Others/, Shai Hulud, 2003 #+end_verse Emacs and vi have long histories, each back to 1976. As editors based on them in some way have seen extensive use through all of the evolution of text and its structure (not to even mention the evolution of computers!) in the intervening 47 years, they over all newer editors can evidence the claim that their systems are capable. But what are the material grounds for this capability? In both cases, the strategy is extensibility, but the tactics could not be further apart. The vi perspective (in line with the UNIX perspective) starts from the assertion that everything on a computer can be fundamentally identified with text. Text in the filesystem is the substance of programs and that on which programs operate; it is what they produce and consume, and that by composing individual programs that perform simple text manipulations one may arive at powerful systems from simple parts. Programs are configured through filesystem text, either with a declarative config file or by modifying and recompilng their source. Programs are accessed through (not necessarily filesystem) text, by typing their name into a shell (which can only take text input, and can only output other text and side-effects). Even hardware devices are accessed through filesystem text, by reading and writing under the =/proc= and =/dev= trees. The text editor's task is merely to present the contents of the static fraction of this text for human consumption and modification, using in no small part the extant systems for text manipulation to this end. The user's enhancements to the system then contribute jointly to the operation of the system and his prowess in the editor---vi ever-growing in functionality /precisely/ on account of its minimality and, therefore, independence of the text-manipulation tools with which it shares a system. By contrast, it seems the Emacs perspective is that text is merely the substance of which programs and the data they operate on can be /composed/, but is not what they /are/. That text is merely a description of procedures to be performed. Therefore, we need not invoke those procedures through particular text incantations in a shell (though we may), nor must all procedures interface through the intermediary of a text terminal or terminal emulator (though, again, they may). The text editor exists more generally to describe and control computer behavior, to intercess between the user and the system---which, yes, often takes the form of reading, writing, and executing text, but which also may be keystrokes bound to functionality, pictures and animations presented to the user, or interactive graphical displays. vi people have recognized this to an extent, mercilessly abusing terminal control codes to get colors and interactive animations in their shells, polluting their textual paradise with programs graphical in all but the most distorted sense (ever tried to /write/ a TUI from scratch?). Emacs by contrast has no such philosophical restrictions, so it may be principled about drawing, using code and protocols actually /designed/ for the purpose from the ground-up. Emacs is configured in Lisp. The language family represents a fixed point in the relationship between programs' identity and programs' composition. Homoiconicity, there being no structural distinction between a Lisp's representation of the data it operates on and the code doing the operation, enables ordinary Lisp code to reason about other Lisp code with the same primitives used for reasoning about anything else---no weird templating, interpolation, parsing, or quoting. Just =macroexpand=. It's a dead-simple language, with about 5 pieces of fundamental syntax (lists, procedure calls, quotes, quasiquotes, and namespace distinguishment). Other dialects can be implemented with about 10 primitives (see the [[https://mitp-content-server.mit.edu/books/content/sectbyfn/books_pres_0/6515/sicp.zip/full-text/book/book.html][wizard book]]). It's extremely expressive---most modern CAS (for a fact: Maple, Wolfram/Mathematica, and SageMATH) drew on theoretical advances made by the MACSYMA system, written at MIT in Maclisp for the PDP-6 starting in 1968. Sage is actually said to have some of that original mainframe Lisp code, albeit ported to CommonLisp, surviving in its core routines. Configuration in a general-purpose language like this enables the editor's functionality to change as its users' preferences, requirements, hardware, and operating systems do. The actual, runtime state of configuration variables can be inspected and changed on the fly. The entire system can be modified, replaced, extended, abused, hacked, introspected, exported, and any other passive-voice verbs you can think of, at runtime, to hearts' content. People have implemented about as complicated and diverse functionality as anyone can imagine in Emacs Lisp, from [[elisp:(describe-package 'eieio)][object systems]] to [[elisp:(describe-package 'cats)][libraries of categorical programming abstractions]] to [[elisp:(describe-package 'elforth)][Forth emulation modes]]. The vi-style editors are hardly a monolith, but on account of their heritage they err on the side of the static UNIX Conf file for extending user behavior. The original was literally this; vim has vimscript (🤣); neovim, Lua (respectable, but far from mature). Nothing like Emacs' ecosystem, where code from the times of the dinosaurs is still found in the repositories, maintained, used, and extended. From a user perspective, the fact that all keystrokes in Emacs are user-configurably bound to Lisp functions (or Lisp wrappers of C functions) is paramount. One may attach any and all of this extensive functionality to any key combination in any way, at runtime, in any way you desire. And so it has been since Stallman's FOSS port to GNU in 1984. Programs written in Emacs Lisp, distributed and installed just as other programs, are used as substitutes for command-line alternatives, written in bash or C. To be clear, no generality or speed need be lost: Emacs can interact with the C ABI and command-line programs just as vi-based editors can. Instead, that generality and speed is made to balance against ease of development and use, a balance most seem to have struck against developing code externally first. Which, probably, would mean that more extension would have been developed for vi, had its users the same option (look no further than neovim's adoption of Lua). Emacs is additionally self-documenting. In the Common Lisp tradition, every package, module, variable, function, and macro can be adorned with a docstring. These docstrings can be used to dynamically produce documentation pages for variables and keybinds, as you forget them in real-time. Emacs' use of prefix keys (e.g. =C-x=, after which the keystroke =b= will mean the Lisp function =switch-to-buffer= rather than insertion of a =b= character) enables packages that, by runtime-querying the current keymap, will tell you all the available next-step bindings and their functions in a key sequence if you wait too long. If you forget what a key does, or want its function to use in a script, =C-h k= will let you type it in and will present the documentation page of the function to which the key combination is bound. Similarly, under =C-h= are many other facilities to bring up documentation pages, which, after some configuration, will present the command, its arguments, its docstring, any manual/info entries about it, links to the documentation of other functions in close relation to it, any relevant key bindings and their mode map, its source definition (whether C or Emacs Lisp), other calls to it from the source (C or Emacs Lisp), options to trace calls of it, and more. I wrote my first Emacs major mode in a weekend, knowing zero Emacs Lisp beyond what I had copied verbatim from David Wilson's /Emacs from Scratch/ videos, and was distributing it among my research group the following Monday. It's difficult to overstate its power. Finally, Emacs is comparably performant to the vi ecosystem. Implementing most of the editor's functionality as modules in a scripting language means that most of Emacs' deep functionality is simply /not present/ unless explicitly loaded, either by an explicit require or as a dependency of another module or function invoked by the user. Currently, =(emacs-uptime)= returns =2 days, 9 hours, 50 minutes, 6 seconds=. Most of this time has been spent heavily loading packages to test, evaluating at some level all 6000 that're either built-in, on ELPA, or on MELPA to craft this config. Yet a simple =free -h= from the terminal reveals usage of only 602MiB, even under X, with =eww=, several info manuals, and a several-thousand-line, rich-text org document all open, among other things. That's less than the startup, idle RAM usage of some entire desktop environments, and when you consider that Emacs /is/ my desktop environment...this old, Librebooted T60 has struggled more to run certain /package managers/ than the heaviest of tasks Emacs editing throws at it. Emacs is, as the GNU project puts it, "/the/ extensible, customizable, self-documenting, real-time display editor." The vi ecosystem is but a pale imitation on each of those three dimensions, and so the Emacs way seems clearly the fastest towards a more principled, deeper, and enjoyable mode of human-computer interaction. * How to Use This Configuration If you're completely new to Emacs, drop everything and type =C-h t= (hold down ==, and press =h=, and then =t= after releasing =h= and ==). This will explain the basic buffer navigation and editing commands and some terminology. After finishing that (you can go back at any time by typing the same thing), type =C-h C-h= (=h= with == held down, done twice) to see all of the other places you can get help. The manual, accessed via =C-h r=, is quite helpful (if you press =u= for "up" a bunch, you can get to the top-level info directory, and read info manuals for other things on your system within Emacs!)---press =h= in the manual to get an overview of how to read it. Place this org file under =~/.emacs.d/=. Once Emacs is up-and-running with this configuration, simply saving this file after making changes to the config snippets will result in those changes being written out to an =init.el= file in this directory, which will be loaded by Emacs at startup. However, this init file must be working in order for the setting enabling tangle-on-save to be set. The first time, you can type =M-x org-babel-tangle= (bound to =C-c C-v t=) to produce it, and it should (hopefully) work painlessly after restarting. This is intended to be read in tandem with other sources of documentation; particularly, the manual and built-in help facilities mentioned above. =C-h r= at any time should return to the Emacs manual, and when in doubt, spam =C-g= a few times before rerunning. To see exactly what something in the configuration snippets is doing, press =C-h o= with the point near the thing in question and it should be the first completion candidate (otherwise just type it in like a plebian 😎). If any functionality seems useless or undesirable, add =:tangle no= to the header line (after =emacs-lisp=) in the relevant source code block. To add your own functionality, create a code block by typing = λ in Emacs Lisp mode, ;; or \alpha -> α in TeX-mode (global-prettify-symbols-mode t) ;; Enables fonts' ligature support---Iosevka has some good ones. (use-package ligature :if (display-graphic-p) :config (global-ligature-mode t) (ligature-set-ligatures '(prog-mode org-mode) '("-<<" "-<" "-<-" "<--" "<---" "<<-" "<-" "->" "->>" "-->" "--->" "->-" ">-" ">>-" "=<<" "=<" "=<=" "<==" "<===" "<<=" "<=" "=>" "=>>" "==>" "===>" "=>=" ">=" ">>=" "<->" "<-->" "<--->" "<---->" "<=>" "<==>" "<===>" "<====>" "::" ":::" "__" "<~~" "" "/>" "~~>" "==" "!=" "/=" "~=" "<>" "===" "!==" "!===" "=/=" "=!=" "<:" ":=" "*=" "*+" "<*" "<*>" "*>" "<|" "<|>" "|>" "<." "<.>" ".>" "+*" "=*" "=:" ":>" "(*" "*)" "/*" "*/" "[|" "|]" "{|" "|}" "++" "+++" "\\/" "/\\" "|-" "-|" "