Hi Kyle, thanks for the thoughtful analysis. On Wed, May 20, 2020 at 12:51 AM Kyle Meyer wrote: > So it looks like the member call above is returning nil because the > prompt markers are corrupting the element. If that's the case, it seems > like the output cleansing should happen upstream of that call. > > What do you think? After a bit of tinkering, I realized there are two things going on here, only one of which I fully understand: 1. My core functional issue is that =comint-prompt-regexp= isn't set up to handle the "Prelude| " entries or the repeated prompts. The other patches I submitted were unnecessary. 2. The =comint-prompt-regexp= gets default values from somewhere I don't understand and can't find with a quick source grep. In ob-haskell, we set =comint-prompt-regexp= to the (undefined) haskell-prompt plus "or optional-lambda": (defvar haskell-prompt-regexp) (defun org-babel-execute:haskell (body params) ... (setq-local comint-prompt-regexp (concat haskell-prompt-regexp "\\|^λ?> ")))) That causes an evaluation error that prevents the first source block evaluation but, strangely, that also results in this mess in the *haskell* buffer on subsequent evaluations: : "^\\*?[[:upper:]][\\._[:alnum:]]*\\(?: \\*?[[:upper:]][\\._[:alnum:]]*\\)*\\( λ\\)?> " =comint-prompt-regexp='s variable documentation calls out much simpler regexps that do basically the same thing as the one above and handles the repeated "Prelude| " entries. This one is based off the Canonical Lisp example: : "^[^>\n]+\\(> \\)?" I've attached a patch against git master that results in fewer undefined variable errors and depends less default-variable magic. Now, =haskell-prompt-regexp= and =comint-prompt-regexp= are explicitly set using defaults that can be M-x customized, and the default value handles the repeated "Prelude| " entries without breaking the original "λ> " prompt handling. Thanks, Nick