←back to thread

Emacs Lisp Elements

(protesilaos.com)
348 points robenkleene | 1 comments | | HN request time: 0.197s | source
Show context
tikhonj ◴[] No.43667636[source]
I've had a great time using Emacs Lisp over the past 15 years: it's one of the easiest ways to quickly whip up personalized tools for my own use, and, at the same time, my code has been surprisingly resilient and stable over this time.

And this is despite the fact that Emacs Lisp routinely flouts every single software engineering "best practice". The language is dynamically scoped by default! It simply doesn't have namespaces! Static types? Hah! (And I, an inveterate Haskeller, don't even miss them.) You can—and people routinely do—hook directly into all sorts of implementation details from other parts of the codebase.

And yet it just works. And it works remarkably well.

My theory: what matters isn't "best practices", it's have a coherent conceptual design and code that reflects that design. Emacs is designed around a small but expressive set of core concepts that it uses in a consistent manner. Text with properties, buffers, modes, commands, customization variables... Almost everything more complex in Emacs is structured out of these (+ a handful more), and, once you've internalized them, it's surprisingly easy to both learn new higher-level tools and to write your own.

The design of both the user interface and the code directly reflect these concepts which gives us a naturally close connection between the UI and the code (it's almost trivial to jump from an interaction to the code that powers it), makes both UI and code units effortlessly composable and generally makes it easier to understand what's going on and how we can change it.

replies(4): >>43667712 #>>43668618 #>>43671691 #>>43673457 #
golly_ned ◴[] No.43668618[source]
I’ve consistently failed to make writing elisp net positive for me for basically anything. I use it as a configuration language, and even then, for functions longer than a few lines, it’s still a lot of coding for very little benefit. I just can’t find things to improve in such a way that it’ll actually be worth writing elisp code for, especially compared to other tools (like a quick Python script or even a bash one-liner), or things within Emacs. What are the things you’ve written in elisp that have helped you?
replies(5): >>43669716 #>>43671521 #>>43672805 #>>43674680 #>>43688133 #
1. 3036e4 ◴[] No.43671521[source]
I wrote a few simple helpers for special things I want to do in (mostly) org-mode, but 99% of "my" elisp is code that I copy-pasted into init.el from someone else. I love that small additions like that can be done by pasting a few lines of elisp into init.el instead of having to depend on full packages.

A few days ago I happened to see my 1998 .emacs file in an old backup. It was only around 100 lines, but I think most of those lines have survived into my current init.el. The oldest lines are probably over 30 years old now. The API is reasonably stable, but not perfect. My current file has lots of logic to handle running in older Emacs versions.