> Also: no one has managed to explain to me what makes emacs so uniquely capable of interacting with a running interpreter, despite this usually being the USP I hear for “needing” emacs when attempting to Lisp.
As an Emacs user that has to work in teams of non-Emacs users, the answer to this boils down to culture and ecosystem maturity.
Purely technically, there's nothing that Emacs allows me to do with REPL Driven Development that _couldn't _ be done in another editor. Practically? I still haven't been able to even get (sufficiently) started with any editor.
I often have to work on a Rails codebase that takes tens of seconds just to start. Dev cycles in the traditional Edit-Restart flow were so painful that I wished badly to burn this codebase down and rewrite it all in a language and style that supports a Lisp-style REPL. Then I discovered inf-ruby.el in Emacs. It allows me to just edit the code and reload only what's changed. It automatically inserts the correct `module Xyz; ...; end` etc. No more restarts.
I showed it to my coworkers. They shared the pain with restarts. And yet, to this day, none of them have an equivalent to inf-ruby in their editors.
inf-ruby.el is less than 1400 lines of code. It's easy enough to implement in Vim, IntelliJ, VS Code, anything really. But it exists only in Emacs, so far. Why? I'm sure because some Emacs user, once upon a time, wished similarly to have a more Lispy REPL for their Ruby dev work, and just built it. Because they were used to it, from having used Emacs or other Lisps with Emacs.
Compare that to when I first tried to support Common Lisp development on VS Code. A language that already has full support for REPL Driven Development with an interactive debugger built-in. Nope, we aren't gonna use any of that, because in VS Code land, we use LSP. A model that really only works for languages that can be statically analyzed. You want Go To Definition on a method that's included from a module and called on a receiver that's a dynamic variable? Well, sucks to be you, I guess.
So, while people make do with the severe limitations of Solargraph or Ruby-LSP, I use robe.el — which adds lisp style code intelligence by running inside your Ruby process — and get code intelligence that actually works with a language as dynamic as Ruby. Again, robe.el was just there for me to use. Again, there's nothing about Emacs that makes robe.el possible in Emacs but not in other editors. Again, there's no equivalent to it (that I've found) in the ecosystems of other editors.
This is honestly fascinating stuff, so thank you for sharing!
I wonder if it is an exposure issue: only those who use emacs know it is possible and those who know emacs have little incentive to leave their editor-OS.
I guess I’ll have to dig into some of these examples you have shared and see if I can comprehend and/or relocate their magic.
Emacs is weird; some people "get it," some, even after using it for years, just never do. The thing "to get" about Emacs is a knack for quickly automating things. Those with shallow exposure to Emacs think that Emacs users are doomed to tinker with their configs all the time. In reality, that's not entirely accurate. I can share so many fascinating, practical examples where I needed to get something done on my computer, and Emacs either already had all the pieces required or provided me with facilities to build upon.
Exhibit A: One day, while taking notes and having to jump between multiple web pages in my browser, I got irritated by having to jump to the browser, finding the tab, going back to my editor, etc. I wrote a function that lets me control my browser tabs directly from Emacs. Why? Because it's convenient, and because it wasn't that hard to make.
Exhibit B: Few days ago, my colleague was showing me something over Zoom. I didn't want to derail his train of thought, I didn't want to keep interrupting him with: "hey, wait, don't scroll away just yet", "can you share that link with me?", "whoa, hold on a second, I need to write that down", etc. Over the lunch break I decided to solve this problem for myself. I use Flameshot. I checked if there are any plugins for it. Turns out there's an open GH Issue, that's all. So, I wrote a command that checks ~/Desktop folder - that's where my screenshots get dropped, then finds the last .png (if it's created less than 2 mins ago, otherwise prompts for a file), sends it to tesseract (a tool, the existence of which I haven't heard until that moment), then opens the OCRed text in a buffer. Now I can quickly select any area on my screen and retrieve text from it with a single keystroke.
Exhibit C: I use Google Translate directly from Emacs. Which by itself is nothing out of the ordinary. Pretty much every other editor has some kind of plugin for that shit. I was reading articles in a foreign language I'm learning, sending pieces to get translated - again, nothing new here. However, it doesn't translate numbers, and that's normal and totally expected. Yet, I wanted to see numbers in their written form. What did I do? I found the function it calls before sending text to GTranslate API, and using advising mechanism, wrote a function that right before sending a request, searches for numbers in the original text and turns them into written form, and then sends that for translation. Advising feature is extremely powerful and it doesn't exist in any other editor beside maybe Lem - neither VSCode, nor Vim, nor IntelliJ, nor Sublime has that stuff. Did I have to look up GTranslate API docs? Nope. Did I really need to sift through the Emacs google-translate package code? Not really. I just needed to find the function responsible and needed to know its signature. Took me less than 15 minutes and fewer than 30 lines of code, most of which is my comments explaining the hack. I couldn't even find a generic Elisp function to translate numbers to words, I just used some npm package for that.
I can tell you many stories like that: the million reasons why I can't ever abandon Emacs and why I love it. I don't care that traditionalists using IDEs think I'm delusional, I've seen that world - it has its perks but also limitations. My world of Emacs not without its own drawbacks yet it allows me to hack some stupid shit almost effortlessly. I guess tis ain't that stupid if thy shit actually works, eh?
As an Emacs user that has to work in teams of non-Emacs users, the answer to this boils down to culture and ecosystem maturity.
Purely technically, there's nothing that Emacs allows me to do with REPL Driven Development that _couldn't _ be done in another editor. Practically? I still haven't been able to even get (sufficiently) started with any editor.
I often have to work on a Rails codebase that takes tens of seconds just to start. Dev cycles in the traditional Edit-Restart flow were so painful that I wished badly to burn this codebase down and rewrite it all in a language and style that supports a Lisp-style REPL. Then I discovered inf-ruby.el in Emacs. It allows me to just edit the code and reload only what's changed. It automatically inserts the correct `module Xyz; ...; end` etc. No more restarts.
I showed it to my coworkers. They shared the pain with restarts. And yet, to this day, none of them have an equivalent to inf-ruby in their editors.
inf-ruby.el is less than 1400 lines of code. It's easy enough to implement in Vim, IntelliJ, VS Code, anything really. But it exists only in Emacs, so far. Why? I'm sure because some Emacs user, once upon a time, wished similarly to have a more Lispy REPL for their Ruby dev work, and just built it. Because they were used to it, from having used Emacs or other Lisps with Emacs.
Compare that to when I first tried to support Common Lisp development on VS Code. A language that already has full support for REPL Driven Development with an interactive debugger built-in. Nope, we aren't gonna use any of that, because in VS Code land, we use LSP. A model that really only works for languages that can be statically analyzed. You want Go To Definition on a method that's included from a module and called on a receiver that's a dynamic variable? Well, sucks to be you, I guess.
So, while people make do with the severe limitations of Solargraph or Ruby-LSP, I use robe.el — which adds lisp style code intelligence by running inside your Ruby process — and get code intelligence that actually works with a language as dynamic as Ruby. Again, robe.el was just there for me to use. Again, there's nothing about Emacs that makes robe.el possible in Emacs but not in other editors. Again, there's no equivalent to it (that I've found) in the ecosystems of other editors.