What are the most basic concepts of Emacs Lisp, beyond syntax, that every person should learn?

Title.

List structure and recursion.

Is there some kind of crash course type thing that starts off with basics like hello world and works up to more complex things? I have tried to read manuals and documentation but im very much a learn by replicating examples type guy

https://www.gnu.org/software/emacs/manual/html_node/eintr/index.html

The car/cdr thing. They look like lists on screen. But they're really more like a series of pac-mans swallowing smaller pac-mans (or Russian dolls, if you prefer). Every cdr is enclosed by a bigger pacman*. But cars roll on their own. *(Unless it's the cdr of a dotted pair, in which case the cdr too can roll on its own.)

That’s exactly how lists work though. Everything’s a “dotted list” or car and cdr values where lists just always use their cdr to point at the car of the next element

Friends don’t let friends iterate. First you car, then you recurse on the cdr. <- a sentence that would have made zero sense to me 6 months back.

"dotted lists" and car/cdr are my Bane tbh

The concept of buffers as the primary data structure. They are use for interacting with other processes, text manipulation, file interaction, and displaying information.

Edit: I got carried away, so the below aren't really things that everyone has to know… This is more useful: the source code of any function can be opened through a link in the help buffer. This includes builtin libraries like let-alist.el or cl-lib.el. You can dig into anything if you want, all locally inside of Emacs. --- - The reader takes some text and extracts a value that programs will work on. If the reader reads two texts into the same value, there is no way to differenciate them in a program. (This is a fundamental concept for understanding syntax.) `nil`, `'()`, and `()` is one such example. They all read to the same value: nil. An empty list isn't just like nil or just falsy, it literally *is* nil. Another example is `(a b)` versus `(a . (b . nil))`. They read to the same value. - Printing lists A list in Emacs Lisp is made up of a chain of two-element containers. These containers are called cons cells; the first element is the *car*, and the second is the *cdr*. A cons cell is written as `(<car> . <cdr>)`; a list `(a b c)` is `(a . (b . (c . nil)))`. The printer effectively removes all occurrences of `. (` and `. nil` in the printed representation of a cons cell. This is why if you replace the last nil with "x" in the list above to make an *improper list* (also called a *dotted list*), it will print as `(a b c . "x")` instead. This equivalence also applies to the reader. - Quoting. When a program is executed, the source code is read by the reader, then the resulting value is evaluated. But what if I just want some text in the source code be read and not evaluated? (My explanation here might be too detailed, sorry) `quote` is a special form that returns its only argument unevaluated. `(quote (a b c))` will be read by the reader into a list of two elements, then evaluated into just the list `(a b c)`. When the reader sees `'<...>`, it reads it as `(quote <...>)`, and through the special form above you get the `<...>` value itself. `backquote` is a macro that does the same, except when it sees any `,value` or `,@value` forms inside, where it will replace the occurrence with the evaluated result. `(backquote (a b ,(list "c" "d"))` is `(a b ("c" "d"))`, while `(backquote (a b ,@(list "c" "d")))` is `(a b "c" "d")`. The latter *splices* the result, if it's a list, into the surrounding list. backquote is written as `\`value`; the reader will take that and turn it into `(\\\` value)`; the symbol `\\\`` is aliased to `backquote`.

[This video course by system crafters](https://www.youtube.com/playlist?list=PLEoMzSkcN8oPQtn7FQEF3D7sroZbXuPZ7) is really good and fairly recent.

Once I understood that this is _literally_ the simplest data structure that can represent any other one, it all made sense to me.

That is actually very nice analogy with Pacman :-), I like it. But it describes rather somewhat narrow case, albeit very common one, of traversing lists of cons cells. I think car and cdr should be approached together with a concept of cell, i.e. cons data structure, where car and cdr are functions to acces respective part of a cons cell. Cons itself is short of construct, which means construct a cell of two elements. First is returned by car, and second by cdr. Names are historical, and the meaning can be looked up in any article or book about Lisp history. When building lists with cons cells, common practice is to put a value of a list node into first element, the "car part" and next node, I.e. cons cell, into the "cdr part". But that is really a convention when building single linked lists. One can put cons cell into both parts and build in principle any kind of lists or trees. In reality, a n-ary tree, build with cons cell, would be a sort of manual conversion, or explicit construction of an n-ary tree as a binary tree. The conversion is always possible, but in the practice working in such a way with data structures is tedious. If I may paraphrase the famous professeure of emacs devs, it is like working with assembly language, but without benefit of the speed. An interesting thing about data structures, in my opinion is that cons cell (a pair of pointers), seems to be able to build about any kind of other data structures, hashmaps, structures (records), lists, trees etc. It appears to be sort of a "primitive" similar to triangles in graphic programming, where a triangle is the smallest datatype needed to render any surface. Probably the most extreme example I have seen is picolisp, where everything at lisp level is built out of cons cells: symbols, lists, hashtables etc.

"Emacs Lisp Intro" is a node in Info in emacs. Maybe take a look at that.

Yes! Buffers, not files, as the main thing. Once you see this you see how, where other editors complect files and their display, Emacs separates those concepts. Important stuff.

Lisp: cons, nil, lambda. Eliisp: buffers, windows

It's not generally a good idea to recurse when you don't have to. It's slower, and you run the risk of blowing the stack since elisp does not do tail call elimination.

The dev experience: Help and cross-linked documentation for every function, variable and other data type. Apropos to find things that you think might exist but don’t know the name of. Precise jump-to-definition on everything and the ability to hotpatch stuff that doesn’t work.

This stuff is crucial to properly understanding lisp; but based on experience I wouldn't try (again) to introduce them as "basic concepts of Emacs Lisp, beyond syntax, that every person should learn". They *are* fundamental, but nowadays I disagree that *every* person *needs* to learn these things, or that they should be taught early. Unless you're doing ground-up teaching of the language, these are things that you come back to later, once a whole bunch of other things have been absorbed. (You can't avoid teaching that lists are chains of cons cells, mind... that part has to happen pretty quickly.)

Right, I got carried away when writing the comment…

Not only does `(quote DATUM)` evaluate to `DATUM` as read by `read`, such a `DATUM` is considered a *literal object*. This is true both in [Elisp](https://www.gnu.org/software/emacs/manual/html_node/elisp/Quoting.html) and [Common Lisp](http://www.lispworks.com/documentation/HyperSpec/Body/s_quote.htm). That means `(quote (1 2 3))` does *not* mean the same as `(list 1 2 3)`, as `list` guarantees that fresh `cons`es are allocated. I often see the misuse of `quote`, even in the Elisp manual, and sometimes I do it without noticing as well. It’s really something Lisp programmers should constantly remind themselves of.

Are there cases where this can bite? Perhaps a literal list might accidentally be `eq` to another list with the same elements, but I'm curious how this can be an issue. Edit: ah, right, a literal value cannot be modified.

If you never write any destructive operation, then no. However, in Elisp, it’s highly likely that you’ll write destructive operations for performance reasons or just to manipulate data structures in general. For example, [`nconc`ing literal lists *might* cause bugs](https://www.gnu.org/software/emacs/manual/html_node/elisp/Rearrangement.html). Moreover, semantically speaking, a *reference* to a `cons` and another reference `eq`ing to it refer to, well, the identical `cons`. In the spirit of [SRFI 1](https://srfi.schemers.org/srfi-1/srfi-1.html), destructive operations should only ever be used in a “linear update” fashion, i.e. when there is exactly *one* reference to the resulting `cons`.

The first 6 sections of this tutorial, plus backquote and how to inspect non-byte-compiled functions (sections 10 and 11): http://angg.twu.net/eev-intros/find-elisp-intro.html

I see, thank you!

if you have time, take the Coursera course in Programming Languages. Part A is on SML, but it teaches the fundamentals of functional programming. The part B uses racket. This will teach you a solid foundation on which you can embark into learning elisp. ALternatively, read SICP and do its exercises (though the Coursera course is better, IMO).

AFAIR, `lambda` wasn't originally there, or smth like that

Car/cdr are just a low-level implementation details, actually, one don't have to think about them. Even C programmers, who like byte-juggling, don't use machine register names. Because machines change, but languages stay. So I find it pretty weird they are still here. When a programmer wants to use `car`, they don't mean that, but `first`, not `cdr` but `rest` and so on. Destructuring is much more readable than `cadadadadadadadar` and makes sense, in contrast to the latter.

What do you mean by "wasn't there" and *"originally"*? I believe that GNU Emacs, at least, has always had `lambda` (as did Lisp 1.5, I believe).

Would that be `seq-first` and `seq-rest` in elisp? Are they more efficient than `car` and `cdr`? (assuming one has already done `(require 'seq)` of course) Or is it a more philosophical point you're making? My education isn't in programming, so all of this is very informative for me.

> Are they more efficient than car and cdr? From programmer's point of view - they are, one doesn't want to think about implementation details, business logic doesn't care about CPU registers. So when you write an algorithm, it's much easier to think in terms of the task, not in the terms of hardware. When you want a sandwich, you don't want to cut bread, vegetables, cook meat etc.