cider-repl-history is corrupted

[cch1]

Expected behavior

Executing cider-repl-history shows the history.

Actual behavior

Executing cider-repl-history reports Unmatched bracket or quote and shows nothing.

Steps to reproduce the problem

1. Start emacs from scratch.
2. cider-jack-in
3. invoke cider-repl-history
4. quit history (q).
5. invoke cider-repl-history again.

Note that on the first invocation everything seems fine -I can browse all the history.

Environment & Version information

CIDER version information

;; Connected to nREPL server - nrepl://localhost:49283
;; CIDER 1.21.0 (Gràcia), nREPL 1.5.2
;; Clojure 1.11.4, Java 17.0.8
;;     Docs: (doc function-name)
;;           (find-doc part-of-name)
;;   Source: (source function-name)
;;  Javadoc: (javadoc java-object-or-class)
;;     Exit: <C-c C-q>
;;  Results: Stored in vars *1, *2, *3, an exception in *e;
;;  Startup: /Users/cch1/.asdf/shims/clojure -Sdeps \{\:deps\ \{nrepl/nrepl\ \{\:mvn/version\ \"1.5.2\"\}\ cider/cider-nrepl\ \{\:mvn/version\ \"0.58.0\"\}\}\ \:aliases\ \{\:cider/nrepl\ \{\:main-opts\ \[\"-m\"\ \"nrepl.cmdline\"\ \"--middleware\"\ \"\[cider.nrepl/cider-middleware\]\"\]\}\}\} -M:dev:test:cch1:cider/nrepl

Lein / Clojure CLI version

Clojure CLI version 1.11.1.1435

Emacs version

30.2

Operating system

Darwin CCH-2023-MBP-2.local 23.6.0 Darwin Kernel Version 23.6.0: Mon Jul 29 21:13:04 PDT 2024; root:xnu-10063.141.2~1/RELEASE_ARM64_T6020 arm64

JDK distribution

openjdk version "17.0.8" 2023-07-18 LTS
OpenJDK Runtime Environment Corretto-17.0.8.7.1 (build 17.0.8+7-LTS)
OpenJDK 64-Bit Server VM Corretto-17.0.8.7.1 (build 17.0.8+7-LTS, mixed mode, sharing)

[cch1]

Some additional information that might be useful:

• Prior to experiencing this problem, I reached the default max history size (500).  Increasing to 1000 does not solve the problem.
• Using the cider-repl-previous-input (Meta-P) works.
• When I quit cider, I get a slightly different error message:

error in process sentinel: Unmatched bracket or quote.

• I have had this problem on several occasions going back at least six months.
• I have the emacs daemon running.

[cch1]

.cider-history.txt

This is the file the provokes the problem.

[cch1]

The content of the file is clearly very very close to being correct. It would be acceptable to excise the offending history element (manually even) if it could be identified. Is there any metadata from the history reader that could be displayed to guide the user to fixing the corruption?

[cch1]

By manually parsing the file based on what I think the content should be, this entry is one of five (of about 550) that is causing a problem:

"(re-find #\"??-SPV-IN-GATS-.*$\"  \"25-SPV-IN-GATS-56495\")"

Edit: my counting was off by one and I was not handling tagged literals correctly.

[cch1]

I am sure I am missing something, but if an invalid form is evaluated by the REPL, why would it be put into the history? The other four invalid forms are caused by unbalanced delimiters.

[bbatsov]

I don't recall what was my original reasoning, but I assume it was to be able to recall the broken form quickly and fix it.

The problem you're facing, however, is related to the history browser being derived from clojure-mode, which means it fires the clojure-mode-hook and you probably have something there that breaks on unbalanced expressions. I'll patch this up soon and I'll make it easier to find problematic entries in the history, although probably the real fix will be to stop deriving from clojure-mode (which was done for the sake of font-locking mostly).

Can you shave the value of clojure-mode-hook for your setup? (you can get it with C-h v)

I'll thinking about the options we have a bit more.

[cch1]

This is my clojure-mode-hook:

(cider-mode #f(compiled-function () #<bytecode 0x1f6f880c98f0a1ac>) clojure--check-wrong-major-mode lisp-editing-behavior
	    highlight-parentheses-mode paredit-mode)

[cch1]

I've written a clojure program to parse cider history -I learned a lot going through that exercise. It parses the outer layer of the history program and attempts to validate the inner entries with read-string. Unfortunately for me, once I had figured out the nuances of the parsing and evaluation, none of the ~610 entries in my .cider-history were obviously wrong.

I then went on a binary search to find the offending entry and I found it.

[cch1]

.cider-history.txt

This .cider-history file (renamed to placate GitHub silliness) contains exactly one entry -the entry that provokes the error on this ticket.