Hacker News new | past | comments | ask | show | jobs | submit login
A rabbit hole full of Lisp (murilopereira.com)
214 points by mpereira 1 day ago | hide | past | favorite | 36 comments

This article can be seen as an introduction to emacs hacking. It features profiling, hooks, advice, and more emacs developer tricks. I haven't read it fully yet but this looks like a nice way to get to know emacs deeper.

Learning the concepts and ideas behind lisp really expanded my horizons as a programmer. For me, that all started with emacs. Though elisp isn't very fast and has some pain points, emacs as a whole gave me an extremely established customizable code base that I could play around and learn in.

Though it's cliché and often listed as a negative, emacs really gives the user more than just a program to edit text.

> Though it's cliché and often listed as a negative, emacs really gives the user more than just a program to edit text.

I would not recommend emacs as an editor these days to most developers, but it absolutely still remains one of the most visionary and well thought out pieces of software ever written. It is both hilarious and depressing how emacs has been literally decades in the future over all of its 45 years of existence, without even the most obvious clearly superior aspects diffusing into the sea of idiocy surrounding it at a rate faster than one or two decades per feature.

Not everything about emacs is great, or even were great, without downside (for example the extreme malleability and customizable bring a raft of problems as well). But a couple of things really were and in some cases still are just obviously, massively, better without the rest of the world being in any seeming hurry to adopt them.

Incremental search is the prime example. It has finally become ubiquitous, and yet Emacs was basically the only thing that had it for well over a quarter century. As Raskin quipped in The Humane Interface (2000), search is either incremental or excremental (unfortunately he seemingly also tried to steal the credit -- he had an interesting mode-less variant of incremental search in Copy Cat which deserves notice, but it still postdated emacs by quite a few years, and I've never seen him acknowledging emacs as prior art). So I would really love to understand why neither netscape or basically anything else in the 90ies had incremental search, despite often being written in large parts in emacs by people living and breathing emacs such as JWZ.

And to this day emacs remains one of very few programs with a proper (i.e. non-linear) undo system or a clipboard not suffering from severe dementia, or the ability to actually ask "what happens when I click here?".

> I would not recommend emacs

Why not? The whole rest of your comment is nothing but a list of (very good IMHO) reasons to use emacs.

Not OP, but long time (and current) Emacs user and fan who also doesn't recommend it to new folks:


Language servers has made most of the heavy features in dedicated major modes in Emacs sort of redundant; servers provide error checking, warnings, refactoring and so on. The gritty bits are in the server, leaving editors to do the syntax highlighting and project management.

This sounds great, but Emacs doesn't ship with support for them, and Emacs' built-in package management is kinda unfinished.

To get good C support, for instance, I would;

1. Install straght.el for its use-package implementation

2. Pull in the lsp-mode package (or eglot, I suppose)

3. Install ccls somehow, because Emacs won't

4. Pull in the projectile package, because the built in ede is kinda cumbersome

5. Pull in magit, because the built in vc mode is nowhere near as good

6. Configure lsp-mode to grok ccls

7. Pull in emacs-gdb, because the built in gdb-mi is cumbersome

8. Finally get to work

With, for instance, vscode I would:

1. Open a C file

2. Install the recommended extension

3. Get to work

And then C works well, the debugging is ok, and so on.

At the end of all the steps I find Emacs superior to use, but most folks will have higher productivity with vscode.

In Spacemacs i essentially have the sought after experience. It goes something like:

0. Know i will be working with C, expect that a C layer should exist

1. Open the docs for the C layer with SPC h l <search for C>,

2. In there, search how to set it up to use a lsp backend

3. add (c-c++ :variables c-c++-backend 'lsp-ccls) and lsp to the list of layers

4. install ccls with my distros package manager

5. restart emacs and get to work

Sure, there are some more steps, but i don't really see it as a burden. And oftentimes it's even easier than that - open a file, get prompted to automatically install the appropriate layer, wait a bit while it does it's thing and you're ready to go. Ok, you should also uncomment the git layer in the configuration but it's already there.

So yeah, i do recommend Spacemacs to the developers i know if they think they might be into a keyboard-centric experience to using the editor and other benefits that Emacs brings (buffer management is a big one for me). It was easy enough for me to jump on using it, without being familiar with Emacs beforehand and without knowing elisp. You do have to know basic vim, though.

I use spacemacs in Holy mode, you don't actually need to know basic Vim. I use only emacs based key bindings.

How to use spacemacs on windows?

Emacs is available on Windows so just install it and then clone the Spacemacs GitHub repository to C:\Users\<username>\AppData\Roaming\ and rename it to .emacs.d\ As i remember, though, i think it was slower than on Linux, but might be something else was going on with my setup back then.

I've also tried running it from WSL. Running it in cli mode was sufficient for me, but i was also able to use GUI mode by installing an X Server (VcXsrv i think) on Windows and making WSL work with that. It makes sense to use it from WSL, if you do your development work there as well. Also, it was before WSL 2, so i don't know if anything's changed now.

and now we have lsp major modes in emacs, with key bindings.. plus various plugins ie magit, org-mode, etc.. butterflies indeed (re xkcd).. ideal workflows in vscode are still a (same) mess of plugins, which are starting to go non foss.

I don't have anything against Lisp, I program Emacs with it, but wouldn't you get mostly the same features if Emacs used Javascript for its programming, for example?

I think this is a good counter point, which is why I made a version of emacs fully scriptable from javascript and typescript [0]

[0] https://github.com/emacs-ng/emacs-ng Disclosure I've posted about this on HN in the past, but I felt it was very relevant to the parent comment.

I've been pondering this for a while. I think you could have a JS-based editor that approaches or achieves what emacs offers, but I haven't encountered it. One useful thing about emacs and elisp is that lisp is one of the primary modes of interaction for users, whereas (IME) many JS-based editors seem to hide JavaScript from you to some extent.

Not in the sense that it's not there, or that there's a second language that the JS interprets. But when you open emacs without specifying a file to open you are dropped into a buffer called *scratch* which lets you directly execute elisp code. It really is a central part of the experience of using emacs. Similarly, your configuration file(s) are written in elisp, versus often a subset of JavaScript (perhaps JSON) used in JavaScript-based editors. And you're not just supplying configuration data, but extending the program.

And then there's completeness. While emacs has parts written in C, that portion really exists to enable elisp. Essentially every capability of the editor is directly reachable through lisp. The same doesn't seem (or at least feel) true of JavaScript-based editors I've tried. In those, it often feels more like the creators have selected a portion of the internals to expose to users, but it's more the minimal amount needed rather than the maximal amount possible that emacs strives for.

EDIT: I've finally figured out how to insert an asterisk around a word on HN without needing spaces. Is this documented anywhere? Just use double asterisks on either end like


Turns out this is in the FAQ, it's been a while since I looked at the formatting part of that so I guess it changed since 10 years or so ago or I'd forgotten.

The Advent of Computing [1] podcast recently put out their episode 47 which I think provides a sort-of explanation of this line of thinking. The short answer is that the context in which Emacs was originally developed (a contemporary of Unix, and not Unix itself, which was something I wasn't aware of before) emphasized user power and lack of restriction to a much greater degree than much of the current computing landscape does. Why would you lock users or developers into a fixed, defined plugin API when you could write the application in such a way that they have access to whatever they need?

Excluding maybe NodeJS, most of the Javascript you encounter is going to be executed by a browser which has a whole ton of sandboxing and mitigation mechanisms to prevent the big bad web from abusing your computer. I don't blame it for working that way given how few trustworthy (I mean really trustworthy, as in "free range within $HOME") actors exist on the web these days, but one wonders how far we could take the web ecosystem if we tossed the idea of granting special access through WebGL or WebUSB and just gave the browser full access to calling C or executing processes on your system.

Don't get me wrong - it would be a security nightmare, but there's a cost to trying to guarantee security through mechanism rather than trust.

[1] https://adventofcomputing.libsyn.com/episode-47-its-open-com...

> While emacs has parts written in C, that portion really exists to enable elisp.

You should do a line count; GNU Emacs has more than 250,000 lines of C.

That remark wasn't about how much is written in C, but what is done with the portion that is written in C (in contrast to the popular JS-based editors). In emacs, the portions in C appear to mostly be (no desire to produce an actual breakdown) there for:

1. Handling system calls for IO, networking, display

2. Implementing the elisp language itself

3. Implementing some things so they're faster than raw elisp

And the preference seems to be to expose, to the greatest extent possible, functionality to the elisp users, even if it's actually implemented in C. This is in contrast to the popular JS-based editors which seem to be more interested in a more controlled/limited exposure of functionality to users.

No, js is not powerful enough for getting the same features that Emacs have, because emacs is almost an operating system.

With js you could create a very simplified version, if you remove 95% of the emacs codebase.

Most people just use 1-2% of emacs anyway, and there are editors that just do that, control a simple text editor with js.

Macros and symbols (even though he technically has Symbols) come to mind as indispensable aspects of elisp which cannot be replicated in JavaScript. Ignoring the fact that Emacs predates JavaScript significantly of course.

Aren't macros a just form of code generation?

Yes, but they are an 'in-process' form of code generation. The distinction is important. Especially when you are extending the system on the fly.

A lot of the pain regarding JS build-systems could be avoided with macros (and reader macros/a customizable reader). Babel is literally macros + a reader.

Hey Thiago!

You are mentioned in the essay that contains the article in this HN post btw :)

Check out the Neovim section in https://www.murilopereira.com/how-to-open-a-file-in-emacs/#t...

Aren't cars just a form of transportation? (sometimes cars are just more convenient than walking)

There are plenty of Emacses programmed in C-like languages. Oldest I can remember was Epsilon. "Epsilon was first released in 1984, long before Emacs was available on personal computers, and modestly priced, so it provided an attractive alternative to the usual DOS editors for those accustomed to Emacs."

Corrección:"Programmed" in C, but "programmable" in EEL, simplified C-language.

I guess you could but why would you choose to use javascript?

Extensive discussion about the longer piece of which this is a subset: https://news.ycombinator.com/item?id=25622756

I use Emacs pretty casually, so it's cool to see the thought process of someone that actually knows their way around it when customizing it.

Its too bad you didnt title it:

(((a rabbit hole of lisp)))

Rather (of (rabbit hole) lisp) ?

I think it should be

   (of lisp (hole rabbit))

haha... I havent written any lis since 2000 or so.... so I forgot any proper format...

edit: Why TF was this flagged???

Probably because it's a very low-effort, highly derivative and puerile Lisp humor posted to a hacker site that is written in a Lisp dialect and that receives quite a lot of Lisp-related submissions and discussions, and whose main rule is that comments require substance.

Just a wild guess.

Better luck next time.

Is it auto-flagged, with a regex that doesn't also look for triple opening parens? No human thought the GGP was making anti-Semitic comments about rabbits, right?

tldr -- Author is inexplicably surprised how slow retrieving a directory listing of 70,000 files is over ssh. He installs a fast version of UNIX `find` on remote machine, and writes an elisp wrapper around an rpc to it.

"Rabbit holes" suggest a circuitous journey towards a deceptively simple goal fraught with red herrings and wrong turns. Author appears to be under illusion that reading a play-by-play of that laborious process is somehow entertaining or rewarding.

Not even reading that far:

As I write this I attempt to reproduce the issue by re-adding ‘ffap-guess-file-name-at-point’ to ‘file-name-at-point-functions’. I can't reproduce it anymore.

(Which of course is not to say that the article isn’t an interesting dive into Emacs and elisp.)

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact