Making IELM (Emacs Lisp REPL) More Comfortable | Hacker News Reader

Making IELM (Emacs Lisp REPL) More Comfortable

n16f.net

83 pointsbilliob28 comments

This is a blast to see. I wrote IELM at least 25 years ago, when I was learning eLisp and was frustrated there wasn’t a REPL to help me try commands and learn it. I remember it being quite a thrill when the FSF wrote to me and asked me to assign the copyright so it could be bundled with Emacs. I’m so pleased to see it’s still in use!

I do remember I had to use an awful hack to make it work. Comint expects data from a pipe, but eLisp output is internal to Emacs. The details are hazy now, I but I think I pushed the eval result as stdin to a ‘cat’ process for Comint to ingest the output. I wonder if that ever got cleaned up…

I use IELM regularly, so thanks for writing it!

Looking at ielm.el, it appears it now defaults to hexl, which is part of the Emacs distribution, as cat might not exist on non-Unix platforms. That's wrapped in a condition-case call though, and will still call cat if that fails.

omg this comment is amazing, I am using IELM almost everyday as a REPL for emacs (it's not uncommon for me to open buffers from either eshell or ielm directly). Thanks so much for your work on this.

Author of the blog post here. Not only is it still in use, but I rely on it all the time because I find inline evaluation (M-:) unusable for anything but the simplest command. At the very least I want to visualize the output of the command without it being replaced in the echo area by the next message, and I may want to copy it.

And of course now I have a persistent history of all commands.

Thank you!

There’s also C-h e for those times when you want to review what was displayed in the echo area. Very handy.

On M-: -- My typical approach is to use the scratch buffer, where I can evaluate multiple things and remember the outcomes, macroexpand etc. So, M-: isn't the only alternative to IELM, but there are also things that scratch doesn't work well with, especially when it comes to figuring out what current buffer is, saving point position, debugging, probably more. So, yeah, for more serious stuff, IELM is better.

I always M-x ielm every time I want to modify something in my Emacs or try out a new package before modifying my init.el.

Such a useful tool even if elisp has limited debugging capabilities :)

i discovered ielm last year and it is a great tool. so much so that i wish emacs started with it opened. if you want to do exploration of emacs via elisp extensions ielm is an essential tool i think. thank you sir for your work!

> I’m so pleased to see it’s still in use!

I feel it’s pretty essential to using emacs.

Two alternatives to also know about, if you're new to Emacs Lisp.

* Lisp Interaction mode (like in your `scratch` buffer). Press `C-j` to eval the expression to left of the point, and insert the result in your buffer. Then you can leave the result there, edit it into a new code, undo to hide it, etc.

* Emacs Lisp mode (like when you're editing any `.el` file) can also do a lot of things that people normally do in a REPL. Say, you're working on some code in the file, and it's running, and you want to change one of the functions. Just edit the function in the file, and hit `M-C-x` to evaluate the `defun` that the point is in, and see the value in the echo area. Or evaluate a region, or the entire file. (At one point, I also had a pretty-printer hooked up, so that it could do better transient display of values.) You can also selectively instrument functions for Edebug from here.

This seems simple today, but it used to blow away the development languages and tools most people were using.

If we're in the business of listing alternative ways to evaluate elisp (not to diminish IELM or the elisp modes of course), I can think of two other common ways to evaluate elisp.

* Eshell (launched with M-x eshell) is a shell in Emacs which uses a language that has elements from elisp. In particular, expressions in parentheses are evaluated as elisp forms [1]. Eshell is a shell (like e.g. bash), so it also has syntax to conveniently evaluate external commands, though it lacks some common shell functionality such as job control [2] and some types of redirection [3].

* Org Babel elisp source blocks [4,5]: In Org mode, use "#+begin_src elisp" and "#+end_src" to delimit lines with elisp and evaluate using C-c C-c, which will, by default, insert the result of the evaluation below the source block. This can be useful, if you want to keep a more organized record of the evaluated commands and their results in comparison to a REPL.

[1] https://www.gnu.org/software/emacs/manual/html_mono/eshell.h...

[2] https://www.gnu.org/software/emacs/manual/html_mono/eshell.h...

[3] https://www.gnu.org/software/emacs/manual/html_mono/eshell.h...

[4] https://orgmode.org/manual/Working-with-Source-Code.html

[5] https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-...

I'm loving emacs a lot more now because of chatGPT, being able to ask quickly how to do XYZ in dired mode, or get a some elisp function to combine two common operations, it's been nice being able to just ask and get the answer in 20 seconds rather than reference the emacs manual

I'll give this a try later. I do recommend learning how to use info mode though, it's very powerful.

Forgot to add, also checkout Rash, made in racket, you can combine bash commands with racket

https://rash-lang.org/

Same here. Been struggling to remember idiomatic ways to write Elisp. But now with ChatGPT as a tutor I am writing a ton of Elisp to do all sorts of non trivial text transformation stuff, things I‘d have used Python for.

I used chapGPT to figure out how to get the same information that appears in *buffer-list* - it was a pretty quick session.

I somehow have been using Emacs for 15 years without knowing such a thing existed. I've been using lisp-interactive-mode for this purpose.

Same here! I will definitely check it out.

Yeah, it's interesting that Emacs has ended up with lisp-interactive-mode as the primary "REPL" (even though it's not exactly the same thing). Kind of like the type-anywhere interactive input in Commodore BASICs vs using a dedicated line.

I've written about all the different methods here:

https://www.masteringemacs.org/article/evaluating-elisp-emac...

This is a great guide!

"I somehow have been using Emacs for 15 years without knowing <thing> existed"

could be the emacs manual title (or any large system tbh)

I've been using Emacs for over 30 years without ever needing such a thing. Just evaluate in scratch, keep what you want, delete the rest.

I have been using Emacs ~50 years, and I have always hoped all of the history would be visible as lisp-expressions which you could view and modify in interactive mode.

It is somewhere there because undo knows it. Typical example is that you fumble something splendid/stupid with fat fingers and then cant figure out what you just did.

Googled it and there is already

    (global-undo-tree-mode)
    (setq undo-tree-auto-save-history t)
    (setq undo-tree-history-directory-alist '(("." . "~/.emacs.d/undo")))

I did not know that.

I think C-h l (lossage) shows the keys and function names.

Yes it does.

Why did not I know that?

-- Because (view-lossage) is weird name for this.

Agree ... I don't know where the name comes from, but I've become used to it since I use C-h l frequently.

I asked chat gpt about it, and what it said seemed to match what I found when I googled it:

> In Emacs, “Lossage” refers to a section in the GNU Emacs Manual that describes how to recognize and deal with situations in which Emacs does not work as expected1. For example, it covers issues such as keyboard code mixups, garbled displays, running out of memory, and crashes and hangs1.

> There is also a command called view-lossage that displays the last 300 input keystrokes2. You can use open-dribble-file to record all your input on a file2.

Reply on news.ycombinator.com