Fossil Files: My .Emacs

Last week, I wrote about cargo culting in a much more general context, so this week I’m going to come clean. The file that had me thinking about the topic was the worst case you’ve probably ever seen: I have a .emacs file kicking around that I haven’t really understood since I copied it from someone else – probably Ben Scarlet whose name is enshrined therein – in the computer lab in 1994! Yes, my .emacs file is nearly 30, and I still don’t really understand it, not exactly.

Now in my defence, I switched up to vim as my main editor a few years ago, but this one file has seen duty on Pentiums running pre-1.0 versions of Linux, on IBM RS/6000 machines in the aforementioned computer lab, and on a series of laptops and desktops that I’ve owned over the years. It got me through undergrad, grad school, and a decade of work. It has served me well. And if I fired up emacs right now, it would still be here.

For those of you out there who don’t use emacs, the .emacs file is a configuration file. It says how to interpret different files based on their extensions, defines some special key combos, and perhaps most importantly, defines how code syntax highlighting works. It’s basically all of the idiosyncratic look-and-feel stuff in emacs, and it’s what makes my emacs mine. But I don’t understand it.

Why? Because it’s written in LISP, for GNU’s sake, and because it references all manner of cryptic internal variables that emacs uses under the hood. I’m absolutely not saying that I haven’t tweaked some of the colors around, or monkey-patched something in here or there, but the extent is always limited to whatever I can get away with, without having to really learn LISP.

This ancient fossil of a file is testament to two things. The emacs codebase has been stable enough that it still works after all this time, but also that emacs is so damn complicated and written in an obscure enough language that I have never put the time in to really grok it – the barriers are too high and the payoff for the effort too low. I have no doubt that I could figure it out for real, but I just haven’t.

So I just schlep this file around, from computer to computer, without understanding it and without particularly wanting to. Except now that I write this. Damnit.

Featured image: “A Dusty Old Book” by Marco Verch Professional.

63 thoughts on “Fossil Files: My .Emacs

  1. So, LISP is an older, and arguably better, language than most of the application scripting languages out there, and definitely older than most of the weird markup formats people use for configuration files. And S-expressions themselves are at least as good a markup format as whateverML in an absolute sense.

    Even the Emacs *variant* of LISP is older than most of those languages.

    I don’t think you get to complain about “obscure languages”. I think you need to complain about newer formats reinventing the wheel, usually badly and for no reason, when they could have just adopted an existing working language.

    1. > older, and arguably better, language … than most of the application scripting languages out there

      Thank you for including the “arguably” there. I’ll bite! :)

      > I don’t think you get to complain about “obscure languages”. I think you need to complain about newer formats reinventing the wheel, usually badly and for no reason, when they could have just adopted an existing working language.

      Um, so full throttle ahead: ELISP is *not* a good language, it’s overly complicated to achieve simple things, and lacks a lot of important features. It is **very** good things modern languages exist; the productivity, ease, sanity and bug-proneness of writing LISP would have made the rest of the world as agile as emacs. Let’s face it: LISP is an interesting language for almost only historical reasons.

      It stands to reason that modern languages weren’t all developed by people who hate themselves, but by people who actually saw the shortcomings of languages like LISP and solved them. It’s an iterative process, like any technological advancement. You’re basically the same as people claiming that “cars these days are simply worse in every aspect but unnecessary bling than 40 years ago”. That just ignores the number of fatal accidents per million driven kilometers, fuel efficiency, ease of handling and adjusted cost, and it ignores developer productivity, and satisfaction.

      So, while LISP, common LISP and consequently elisp are certainly nice wheels to reinvent, other languages went ahead, said, hm, maybe wheels would be better if we didn’t do them with five corners but round-ish, and maybe, let’s also give developers guidance and syntactic assistance on how to build vehicles with those wheels, that would make for better wheel ecosystems.

      So, yeah. I think it’s cool that you like LISP. But LISP really *is* an obscure language, just as ancient Greek is nowadays: Used in specific niches, all people writing it as their main occupation probably nicely fit in a medium sized bus.

      Let’s constructively complain about important software being built on languages so bad. It’s going to bring humanity forward :)

      1. But you haven’t made any constructive complaints. You’ve just handwaved, and repeatedly asserted “Lisps are bad, m’kay?” What shortcomings do you believe other languages have fixed? What important features for implementing text editors does ELisp lack?

        1. The original article, and all replies leading up to here, lack constructive complaints, so I think it is hardly fair to demand that new replies contain them. Instead, all I read are vague claims that either say “lisp is good, newer stuff bad” or the opposite. That is the quality bar new posts must clear.

          I’ll just say that I’ve used Emacs for 30+ years, learned and written a few smaller projects in Common Lisp, dabbled in scheme, worked my way through PAIP, etc. Through all that I’ve come to an emphatic conclusion: given a choice I’ll pick a different language.

          Lisp is like programming with a grape on a plate. Any argument that some other programming language is better can be met with “lisp can do that too!” Of course it can, because it is really just a small set of primitives and a bunch of macros and functions layered on top.

          Lisp’s weakness is that it is too flexible. Programmers can always make functions and macros that express their ideas in a concise way. Misusing those macros and functions often results in terrible error messages. One little typo, piece of punctuation, say a ‘ or `, can radically change the meaning of the code in ways that don’t manifest immediately but instead result in some odd error elsewhere.

          Using lisp I find I’m regularly experiencing little paper cuts that simply don’t happen in other languages. So, I’ll choose them over lisp any day.

          1. Flexibility is Lisp’s strength as well as weakness. To solve a large problem in Lisp, expert programmers start by defining and implementing a new problem specific language. This allows the problem to be addressed at a higher level, presumably more effectively.

            *But* defining new languages is not easy. What is easy is attempting that definition and falling into the pit you describe.

      2. “It stands to reason that modern languages weren’t all developed by people who hate themselves, but by people who actually saw the shortcomings of languages like LISP and solved them.”

        And that explains C/C++.

        1. In a way it does. I’ve talked about C being the best assembly language I’ve ever used. There is no way you could have developed and run Unix on a PDP-11 in Lisp. C has very limited data structure support and C++ fixes that.

          But they both spend programmer time and cost to save hardware time and cost. As programmers have gotten more expensive and hardware less expensive, that is not such a good trade anymore.

  2. Hmmm, my .emacs doesn’t have huge amounts of look and feel stuff in it. It has some stuff that I added so it could deal with oddball languages like Forth and PLM. Mostly telling it where to find the elisp files holding the required code. You would think I might have accumulated more since I started using it in the 90’s.

    I haven’t felt the need to take a deep dive into elisp but I remembered a book I found in the university library so fondly that several years ago I purchased its followup: “The Little Schemer”.

  3. For others who don’t know or use emacs, the .emacs file is a list of interpreted code run by the editor after it boots up. It’s very much like your .bashrc file, in that it’s just a list of things to do that the user wants done.

    It’s normally empty. You put anything you want there.

    Emacs has a zillion interfaces in the form of functions that you can call or variables you can set in this file.

    For example, there’s an association between any file type and a major “mode” of emacs operation that specifies, among other things, the way syntax is highlighted for the language specified by that file type. So a file ending in .c or .h will natively activate “C” mode, a file ending in .js will activate “javascript” mode, and o on.

    This is implemented in pretty-much the way you’d expect: an array that associates (in text) the file extension, and the name of the major mode, which is also the name of the function to call that activates that mode.

    Emacs makes the entire set of variables used in the editor code visible to the user, so that it can be manipulated in the .emacs file using user-defined lisp.

    It runs afoul of the problem of “I only want to do this simple thing”, which is best approached by googling and cut/paste the example from the net: 5 minutes and you’re back doing real work. Your .emacs file tends to collect a lot of these snippets and they get pretty incomprehensible.

    To really understand it, you need to read the manual, go through the tutorial, and try some things out,

    And that’s really the crux of cargo-cult coding: I don’t have the time or interest to read the manual on everything that’s available nowadays, just tell me how to do this one simple thing so I can move on to more important work.

    I’m the same way with virtually every other large package and language: KiCad, SimSmith, javascript, python, .emacs, Apache, Gimp, Blender, the list goes on.

    I don’t have the time or inclination to read the Gimp manual, it’s easier to just google the location of the crop tool and cropping is pretty self-explanatory and then I’ll have the image I need for work.

    That’s cargo-cult coding for me: It’s not that I don’t understand the underlying functions, it’s that I don’t want to take the time to learn everything about something in order to extract a tiny snippet that I need to use right now.

    1. > that’s really the crux of cargo-cult coding

      It isn’t. For some activity to be “cargo-cult”, it shouldn’t actually work or do anything – you just believe it does.

      Cargo-cult doesn’t mean that you’re lazily copy/pasting code you don’t understand – it means you’re going through effort to include code that is actually non-functional or even counter-productive, because you’re so clueless about what you’re doing that your programming is more like a voodoo ritual.

  4. Probably you could delete (rename, probably better, just in case) the file.

    Find out what it doesn’t do that you want anymore.

    Google how to make emacs do X

    Add that to your .emacs file.

    Boom, you understand it, it does what you want, startup only takes milliseconds ( not that you ever restart emacs).

  5. The cargo cult is the maxwell equation of our technology age. No human has understood every tool down to the flint, maybe since they invented beer. Something that could be fired and forgotten forward through generations. Like .emacs

  6. It could be worse. Emacs, and I think VI as well, had its origins in “Control-R mode TECO”, and TECO (especially later generations of it) is darned near as terse as APL though at least it’s all standard ASCII characters.

    Text Editor and COrrector dates back to well before video terminals, and uses mostly one-character primitives to navigate, examine, and modify files. Virtually any string is a legal sequence of TECO commands; one of the games users used to play was to try to invent sequences that looked like text but did something useful.

    As it evolved it developed looping, conditional, and stored-command (macro) capabilities and became as much a programming language for text manipulation as an interactive editor. Eventually the control-R (“realtime”) command was introduced that would start a visual session with keystrokes going to a macro that interpreted them and acted upon them. VI retained the distinction between text insertion and command modes with the same keystrokes doing both; EMACS went non-modal assuming that since control characters were rarely inserted they could be used as immediate commands.

    Quick example to give you the flavor of TECO: To do a global search for foo and insert bar after each instance, displaying each changed line, one might write


    where $ represents the escape character, used to terminate text strings. j moves the cursor to the start of the file, iterates, s searches for the text following it and moves the cursor to just after it, ; exits iteration if the preceding command failed, i inserts a string at the cursor, t without argument prints the buffer contents from the cursor to end of line, with argument 0 t prints buffer contents from the preceding line break to the cursor. Double escape terminates the current command string and starts interpretation.

    Now imagine a large system like EMACS written in that compact write-mostly notation. It’s easy to say what you want to do and to grow the functionality, harder to come back and understand later.

    Compare to that, Lisp is absolutely pellucid. Not that I understand the Lisp implementation of Emacs all that well myself.

    (I “grew up” with TECO, and did some work on documenting TECO and EMACS before RMS ported it to lisp.)

    1. Whups. Forgot that this system was going to suppress anything in angle brackets. Let’s try that again, pretending that curly braces are angle brackets though I believe they did something other than iteration…


  7. I’ve been using Emacs since the 80’s. When I first encountered it, only people employed by the computer center were allowed to have emacs configuration files (which probably had a different name then, this wasn’t on UNIX but TOPS-20 and an initial dot ini its name didn’t hide a file). I never found out the reason for that policy, but maybe it was because they got tired of helping people who had broken Emacs with their settings.

  8. Been using emacs since 1978 (yes I fart dust!) but my .emacs is very modern and changed a lot. I use org-mode to keep my notes and to run my code snippets (SQL, bash, python, etc. under Linux and Windows). I even keep diagrams, pdf, links to other files and systems. It does a lot of what MS Notes can’t do. I wouldn’t have been able to survive all the changes and learning I needed to do without it.

  9. Been using Emacs since the 80s and still do. That fact that I am not fluent in elisp hasn’t bothered me a bit. Is the syntax for vim configuration really all that much more readable to the uninitiated? Realistically you’re still talking about a lot of search, cut, paste, and move on.

    But forget Emacs, vi, vim, or the latest modern gee-wiz IDE. The one true editor is still ed.

    With ed you don’t need no stink’n configuration file.

  10. Emacs sucks !
    This is not as fun as before, when you would 110% start a flamewar with this kind of statement. Now it’s so obvious, nobody cares.. O tempora, O mores.
    My .vimrc is from around 1994, so about 28 years ago. But then again, i’m probably (slightly) younger than you. I keep on changing/updating it. And i can do this, because I understand it ! :)

    1. I guess, just for old times sake, I should respond. vi sucks! I only used it on new systems, just long enough to bring up a real editor — emacs.

      My .emacs file is nearly 40 years old. Sigh. In spite of once being fluent in Lisp, I no longer understand it, nor do my fingers remember emacs control sequences.

  11. I used to be one of those people with a pretty elaborate emacs customization (in fact, for organizational reasons, a whole directory on the side of little snippets of stuff). I understood the contents completely, or at least 98% completely. I was the sort of person that other people came to for emacs customization help. But I don’t do that anymore. I only have a few customization on the machines I use all the time, and they are not critical (background colors, fonts, code formatting rules for work stuff, and a few others).

    What changed? It was part of my own mental adjustment to use, as much as possible, the defaults that someone else had chosen for a system. Moving from system to system, it was so tiresome to get back to the configs and tweaks that I was used to. That’s right … I also no longer have a big bunch of configurations for the X Window window manager (which, of course, was an alternative window manager to the one that came in the box).

    In my younger days, that would have seemed like giving in or selling out or something. Now it just seems like making the best use of my time and my brainspace.

    For the emacs customization in particular, at some point I decided to give it up. Piece by piece, I looked at my customization and decided whether I really needed it or if the default would be fine once I got used to it. It’s kind of lucky that the default behaviors are reasonable most of the time. The hardest thing was that some fundamental key-bindings changed over the years (probably because of the different variations of emacs that I have used here and there).

  12. Rite of engine-spirit appeasement and motivation.

    Strike the first rune upon the engine’s casing employing the chosen wrench.
    Its tip should be anointed with the oil of engineering using the proper incantation when the auspices are correct.

    Strike the second rune upon the engine’s casing employing the arc-tip of the power-driver. If the second rune is not good, a third rune may be struck in like manner to the first.

    This is done according to the true ritual laid down by Scotti the Enginseer.

    A libation should be offered.

    If this sequence is properly observed the engines may be brought to full activation by depressing the large panel marked “ON”.

    Praise and glory be to the Machine God.

    1. “ON” is short for the full name of that button, which was invented (and named after) the russian engineer Поверонов (his friend Килсвич specialised on computer hardware later)

  13. My job is to fix industrial electronic devices, most of times PLCs and servomotor controllers.
    In the last 15 years I learned so much through reverse engineering my path to solve awful failures, and I still learn a lot everyday.
    In the beginning I believed that going low level was all that one needs… Well, high level programming is a great shortcut, but sometimes you simply need to go lower level.
    By that I mean a job that popped up in my bench a couple of weeks ago, where an very exquisite computer from 80’s that (still!) controls a machine simply stopped working, and no documentation or help existed out there.
    I eventually guessed that there could be a memory corruption in one of those EPROMs, and the client was willing to pay the price for the solution, so I started peeking the data buses with 5 computers and 5 logic analyzers (what a mess!) and eventually found the address that messed the things up.
    After some trial and error, and some ancient EPROM killing, I managed to find the corrupted bit in one of the chips and the machine is there doing it’s 24-7 magic again.
    Something I learned is that’s impossible to learn all that there is about any subject, and that’s what make anything simply fascinating to do.

  14. Lisp has always been one of my favorite programming languages. I wrote mostly C++ for the last 20 years of my career, but every time I needed a new emacs behavior and would write lisp for a half hour I would spend the next half hour cursing C++ for being so stupid. Retired now, still love emacs and lisp.

    1. At one point in my career, I was writing in Lisp, C, and assembly language all in the same day. Each time I stepped down a level, I’d feel my productivity drop dramatically. I was bringing up a Lisp environment on a new computer architecture. Lisp if the function was not performance critical, C if it was, and assembly language to take advantage of hardware features. It was a dramatic demonstration of the value of high level languages.

      As much as I loved Lisp, the world has moved past it and that’s a good thing. But I keep running into people using Lisp well to solve current real world problems.

  15. My .emacs (actually it’s ~/.config/emacs/init.el – and early-init.el – now, that’s how kids wear it) is synced on all my machines (meaning I commit every meaningful change, and pull it on all my boxes) and has mutated over the years almost on its own. Each time I encounter a new language, and the associated-and-nearly-mantadory IDE, I just turn Emacs into a better one. Trusty and clever horse, never let me down in nearly 3 decades ; Meanwhile my friends are basically changing editors / hype every 3 to 5 years, poor souls.

  16. These days syntax highlighting works out of the box in Emacs. No need to do any configuration for it.

    Elisp is honestly pretty straight forward and simple as far as languages go. Feels like any longer term Emacs user has no reason not to at least be able to somewhat read it and make a few of their own customizations. Otherwise there’s no real reason to use Emacs (well… Besides org mode perhaps).

    My main reason for using Emacs is I can tailor the editor to my own needs and preferences, instead of having to change the way I think to fit the editor. Unfortunately, I don’t think I can recommend it to new programmers since vscode just does _that much_ out of the box, and makes configuration dirt simple. But I suspect I’ll be part of the last generation of engineers who use Emacs their whole lives.

  17. Emacs might not be the right environment for you. The joy of emacs is that it’s a complete programming system. So if you’re tired of doing some rote thing, you can write a function that does it for you. I agree that elisp is the most awkward of the lisps (although lisp in general is quite amazing and not only useful for historical reasons). I’m not an emacs expert, but I learn a little more each day, and for me that’s a benefit not a loss. I agree though that when you just need to get something done, you don’t have time to learn the world first. But it might not take as long as you think to get through your .emacs file, and it could be liberating.

  18. Actually vi was the “Visual Interface” Bill Joy (of Sun) created for the ex editor, which was his extended version of the original ed Unix editor. No relation to TECO.

    I first used Emacs on the still-greatest-os-ever, Multics, back in about 1981/2. Multics also had TECO and for a while we used to amuse ourselves by typing in our names and seeing what the editor would do.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.