I often use straight-visit-package and find-library to read the READMEs and ;; Commentary: sections in Elisp files. On top of that, I use Info quite extensively - the manuals for Elisp and Org Mode are loaded with tons of useful Elisp snippets.

The problem: while you can use C-x C-e almost everywhere, some of the places listed above are read-only buffers (Info, built-ins from /usr/lib/), so if I want to evaluate it in a slightly changed form (longer than one line, since that would fit in eval-expression), I need to switch to scratch buffer, which is pretty intrusive. With addition of IELM, my workflow looks like this:

1. I'm reading code or docs in a read-only buffer.
2. I find a piece of code I want to play with (modify and execute)
3. If it's one line, I copy it to M-: (eval-expression)
4. If it's up to 10 lines, I copy it to C-M-: (ielm)
5. If it's longer, I copy it to *scratch* buffer

In this post, I focus on pt. 4.

UPDATE: Another kind soul on Reddit (/u/deaddyfreddy) pointed at edit-indirect package that could be a good replacement for this. I will take a look!

Bound under M-: by default, eval-expression allows you to quickly type any Elisp and execute it in the context of current window and buffer. I think it's one of my most used key bindings, after M-x. It supports TAB-completion, and even shows help (function and macro signatures).

The input takes place in the minibuffer, which means it automatically keeps history of pevious invokations. You can search through that history, using your preferred completion styles, for example with Orderless (and Vertico, here) you can use regular expressions to get what you want:

Unfortunately, the minibuffer is not the best way to input more complex forms. Multiline is possible, but tedious. Lack of enabled paredit hurts (and enabling it messes up incomplete input handling). For these reasons, for trying out longer pieces of code, I normally switch to the *scratch* buffer. The downside of it is that I need to switch to a buffer, often losing sight of the buffer I worked with before that.

Fortunately, there's a middle ground: ielm! It's documented with a single page in the Emacs manual and just a handful of customizable options. By default, as is usual for Emacs, it doesn't look or work too well, but with a bit of configuration, it gets a lot better. Here's how I use it.

First, let's make ielm look better. As a replacement for eval-expression it should display at the bottom of the frame. I also prefer it to reduce the clutter - the default headaer and the prompt could use some tweaking:

 1: (cl-defun my-make-right-arrow-icon ()
 2:   "Return a string that displays arrow icon  when inserted in a buffer."
 3:   (propertize (all-the-icons-octicon "arrow-right")
 4:     'face `(:family ,(all-the-icons-octicon-family) :height 1.2)
 5:     'display '(raise 0)))
 6: 
 7: ;; Make *ielm* buffer display in a side-window at the bottom of the frame
 8: (add-to-list 'display-buffer-alist
 9:              '("*ielm*"
10:                (display-buffer-in-side-window)
11:                (side . bottom)
12:                (window-height . 10)))
13: 
14: (setq ielm-header "")
15: (setq ielm-prompt (concat (my-make-right-arrow-icon) " "))
16: 
17: (keymap-global-set "C-M-:" #'ielm)

We use display-buffer-alist to add a rule for where and how *ielm* buffers should show up, then remove the header (why waste a line?) and change the prompt to a shorter one. We get this as a result:

Now, let's make the *ielm* buffer behave more like a normal Elisp buffer. I have a lot of config already in place for Elisp, and since the buffer is not a minibuffer, most of these will just work. So, I add a few hooks:

 1: ;; *ielm* buffer
 2: (add-hook 'ielm-mode-hook 'my-elisp-mode-setup) ; (1)
 3: (add-hook 'ielm-mode-hook 'my-ielm-mode-setup)
 4: (keymap-set ielm-map "C-M-:" #'kill-buffer-and-window) ; (2)
 5: 
 6: ;; indirect buffer used by ielm to fontify elisp code
 7: (add-hook 'ielm-indirect-setup-hook #'rainbow-delimiters-mode) ; (3)
 8: 
 9: (defun my-ielm-mode-setup ()
10:   (paredit-mode)
11:   (keymap-local-set "C-<return>" #'my-ielm-send-input) ; (4)
12:   (let ((map (copy-keymap paredit-mode-map)))
13:     (keymap-set map "<RET>" 'ielm-return)
14:     (push `(paredit-mode . ,map) minor-mode-overriding-map-alist)))
15: 
16: (cl-defun my-ielm-send-input ()
17:   (interactive)
18:   ;; The pattern of: '<return> SHIT, I meant execute! C-/ C-<return>' repeats
19:   ;; iself often enough that automation seems warranted... :)
20:   (when (eq 'ielm-return last-command) (undo))
21:   (ielm-send-input))

my-elisp-mode-setup (at (1)) is a hook I run in normal Elisp buffers. It enables tens of packages and messes with a lot of keybindings, you can see it on Github. my-ielm-mode-setup only overrides some key bindings - paredit would normally hijack the RET key, so we use minor-mode-overriding-map-alist to tell it not to do that. With that, we have a nice multiline editing, structural editing with paredit, and fontification and indentation that work:

With ielm-dynamic-multiline-inputs and ielm-dynamic-return set, we can now insert newlines normally as long as we're not at the very end of the input. Having to move point to the end to execute the code can be tedious, so I bound C-<return> to send the input immediately, no matter where the point currently is.

Since this is a normal Elisp buffer, we can also use C-M-x and C-x C-e to execute parts of the current input. That allows you to refine the input before actually executing it.

Going further, one of the nice things about eval-expression is that it works in the context of the current window and buffer. I didn't want to mess with how IELM executes its input; instead, I made a little helper function:

 1: (keymap-global-set "C-M-:" #'my-run-ielm)
 2: 
 3: (cl-defun my-run-ielm (arg)
 4:   (interactive "P")
 5:   (let ((buf (buffer-name (current-buffer))))
 6:     (ielm)
 7:     (when arg
 8:       (insert
 9:        (prin1-to-string
10:         (pcase arg
11:           ('(4) `(with-selected-window (get-buffer-window ,buf)))
12:           ('(16) `(with-current-buffer ,buf)))))
13:       (forward-char -1)
14:       (ielm-return))))

Now, when I want to execute some code in the context of a window or buffer I was before invoking IELM, I can press C-u C-M-: or C-u C-u C-M-:. This is what I get in that case:

I can now use things like re-search-forward in the context of the window I was in before switching to IELM - and see the point move as the command gets executed.

Finally, remember the "help" that eval-expression offers? Since *ielm* is a normal buffer, it can do a lot more - for example, you can use it with Corfu:

Of course, all the other goodies you have configured for emacs-lisp-mode will also work. This is the ultimate advantage of this solution over eval-expression, in my opinion.

One thing missing is saving and searching of the history of commands. It's kept in comint, I think, and is not persistent. Recalling previous commands in a single IELM session (with C-<up>) works, but C-r starts an isearch of the buffer instead of Orderless search with Vertico. This is something I still need to figure out.

UPDATE: a kind soul over at Reddit (/u/FrankLeeMadear) provided the missing piece for me! Thank you, I will use it well! 🙂

 1: (defvar ielm-input-ring nil
 2:   "Global to hold value of input ring. Add this to savehist-additional-variables")
 3: 
 4: (defun set-ielm-input-ring ()
 5:   ;; called only when ielm is current buffer
 6:   ;; init local var from global saved by savehist
 7:   (when ielm-input-ring
 8:     (setq comint-input-ring ielm-input-ring)))
 9: 
10: (defun save-ielm-input-ring ()
11:   (let* ((buf (get-buffer "*ielm*"))
12:          (ring (and buf (buffer-local-value 'comint-input-ring buf))))
13:     (when ring 
14:       (setq ielm-input-ring ring))))
15: 
16: (add-hook 'ielm-mode-hook 'set-ielm-input-ring)
17: (add-hook 'savehist-save-hook 'save-ielm-input-ring)
18: (add-to-list 'ielm-input-ring 'savehist-additional-variables)

Other than that, I think this config fits nicely between eval-expression and visiting an Elisp buffer (scratch or otherwise). I've been using this for a few weeks to experiment and play with new libraries. Being able to choose in which context the code will be executed is convenient, and the full power of structural editing and completion with Corfu even for throwaway snippets helps a lot when exploring and prototyping code.

Here's the link to the exercise - as usual, we get some input data, and need to read it and check some of the properties. In this case, the question is as follows:

Determine which games would have been possible if the bag had been loaded with only 12 red cubes, 13 green cubes, and 14 blue cubes.

Okay - before we start, let's import the libraries we'll need. Strictly speaking, none if these are actually needed - you can see other implementations that don't use anything outside of subr and simple - but I want to showcase the tools modern Elisper has at their disposal.

1: (require 'b)
2: (require 'cl-lib)
3: (require 'map)
4: (require 'dash)  

With that out of the way, we can take a stab at the task. First, let's assume we have the input in a buffer already, in input.txt. You could implement the task by imperatively traversing the buffer, which would be very Emacs-y way of doing this, but since there's an implementation like that already, I'll go for a more Python-like approach and split the input into a list of lines:

5: (defconst aoc-games-played-input
6:   (-> "input.txt" get-buffer b-string-no-properties s-trim s-lines))

We now have 100 lines of text, ready to be further processed:

(length aoc-games-played-input)

100

Here's how the lines look like:

(-take 2 aoc-games-played-input)

("Game 1: 12 blue, 15 red, 2 green; 17 red, 8 green, 5 blue; 8 red, 17 blue; 9 green, 1 blue, 4 red"
 "Game 2: 6 red, 6 blue, 2 green; 1 blue, 1 red; 6 green, 1 red, 10 blue")

We need to verify that on each line all the "subsets" - separated by semicolons - have color values that do not exceed the limits quoted at the beginning. First, let's further split the lines into chunks, separating game ID from subsets, and then further separating subsets from each other:

(let ((line (car aoc-games-played-input)))
  (pcase-let*
      ((`(,game ,subsets) (s-split (rx ": ") line))
       (subset-list (s-split (rx "; ") subsets))
       (subsets (--map (s-split (rx ", ") it) subset-list)))
    (cons
     (cl-second (s-match (rx "Game " (group (1+ num))) game))
     subsets)))

("1" ("12 blue" "15 red" "2 green") ("17 red" "8 green" "5 blue")
 ("8 red" "17 blue") ("9 green" "1 blue" "4 red"))

It works, so let's refactor it a bit before moving on. As we're doing the refactor, we can also convert strings to numbers and symbols as appropriate, and subsets into alists:

 7: (cl-defun get-game-id (game-name)
 8:   (let ((re (rx "Game " (group (1+ num)))))
 9:     (->> game-name (s-match re) cl-second string-to-number)))
10: 
11: (cl-defun subset->alist (colors)
12:   (cl-loop for color in colors
13:            for (num color) = (s-split (rx " ") color)
14:            collect (cons (intern-soft color) (string-to-number num))))
15: 
16: (cl-defun line->game (line)
17:   (pcase-let* ((`(,game ,subsets) (s-split (rx ": ") line))
18:                (subset-list (s-split (rx "; ") subsets))
19:                (subsets (--map (s-split (rx ", ") it) subset-list)))
20:     (cons
21:      (get-game-id game)
22:      (-map #'subset->alist subsets)))  )
23: 
24: (let ((line (car aoc-games-played-input)))
25:   (line->game line))

(1 ((blue . 12) (red . 15) (green . 2)) ((red . 17) (green . 8) (blue . 5))
   ((red . 8) (blue . 17)) ((green . 9) (blue . 1) (red . 4)))

So we have the data in a form that's convenient to work with. Now, what does it mean for a game to be possible? All subsets must have color values within a limit. Let's define a function for checking this:

26: (defconst limits '((red . 12) (green . 13) (blue . 14)))
27: 
28: (cl-defun game-possible-p (game)
29:   (cl-loop for subset in (cdr game)
30:            unless (cl-loop for (color . limit) in limits
31:                            always (<= (map-elt subset color 0) limit))
32:            return nil
33:            finally return t))
34: 
35: (defconst line-impossible
36:   "Game 1: 12 blue, 15 red, 2 green; 17 red, 8 green, 5 blue; 8 red, 17 blue; 9 green, 1 blue, 4 red")
37: (defconst line-possible
38:   "Game 2: 6 red, 6 blue, 2 green; 1 blue, 1 red; 6 green, 1 red, 10 blue")
39: 
40: (list (game-possible-p (line->game line-possible))
41:       (game-possible-p (line->game line-impossible)))

(t nil)

The predicate seems to be working. The two things left to do are to filter out the games for which the predicate returns t and then sum the game IDs of those games:

42: (cl-loop for line in aoc-games-played-input
43:          for game = (line->game line)
44:          if (game-possible-p game)
45:          sum (car game))

2716

And that's, according to the AoC page, the correct answer for my dataset, for part 1!

For completeness sake, here's the answer to the second part of the puzzle. Here, we need to find the maximum values for each color across all subsets of a given game:

46: (defconst maxes '((red . 0) (green . 0) (blue . 0)))
47: 
48: (cl-macrolet
49:     ((alist-maximize (key acc alist)
50:        `(setf (alist-get ,key ,acc)
51:               (max (alist-get ,key ,acc) (alist-get ,key ,alist 0)))))
52:   (cl-loop for line in aoc-games-played-input
53:            for game = (line->game line)
54:            sum (cl-loop with maxs = (copy-tree maxes)
55:                         for x in (cdr game)
56:                         do (progn
57:                              (alist-maximize 'red maxs x)  
58:                              (alist-maximize 'green maxs x)
59:                              (alist-maximize 'blue maxs x) )
60:                         finally return (apply #'* (map-values maxs)))))

72227

The result happens to be correct for my dataset, here too.

The main highlight here is the cl-macrolet form, which defines local macros, valid only in the lexical scope of the form. It's great for getting syntactic clutter out of the way without polluting the global namespace.

A honorary mention goes to setf - a versatile tool for updating contents of things. There are many "things" that you can set/update, and you can your own "places" and have setf work with them, too. The selling point of setf is the symmetry: most often, the "place" has the same syntactic form as the getter for a given thing. Here, alist-get is used with setf to update a value in an alist - it's way cleaner than assoc and setcdr to which it expands to.

Notice also the copy-tree - it's important because of the mutability of Elisp's lists. It's obvious now when the alist is defined outside of the function, but the call to copy-tree would be needed even if the variable was inlined! That is, this:

(cl-loop with maxs = '((red . 0) (green . 0) (blue . 0)) ...)

Would still produce wrong output. An alternative to copy-tree would be constructing the list at runtime by calling list and cons functions. I'll leave the detail as to why this happens for a future post.