Description
Expected behavior
EDN is a plain data format, and its syntax is a subset of Clojure's (eg. no regex / #() function literals).
Should we have a lightweight edn-mode that derives from clojure-mode? That would allow for simpler and faster font-locking and indentation rules - see also #610.
json-mode derives similarly from javascript-mode, it retains all user config on the parent mode hook and keymap, while allowing tools to use the major-mode as an easy indication of what features to enable.
I would open this as a GH Discussion but it hasn't been enabled on the repo, feel free to convert it to one.
Actual behavior
EDN files are fontified and treated as Clojure source code.
A large majority of clojure-mode's font-lock rules are incorrect in this context. Eg. (defn f) in an EDN file is /not code/ but just a list of symbols, however much the line between code/data is blurred in Clojure. Cider goes further by mapping to it the default user ns, allowing for code evaluation, applying complex indentation rules and dynamically highlighting symbols corresponding to clojure.core vars.
The combined weight of so much regex can be significant for large programmatically-generated data files, where I've had to switch off font-lock-mode before due to Emacs choking on long lines.
Additional context
Sometimes the data in EDN actually is code.
In bb.edn files the :tasks contain representations of Clojure code to be interpreted by SCI. https://book.babashka.org/#tasks But these are ad-hoc semantics imposed by Babashka, eg. extra vars aliased for convenience, :requires syntax etc. We could always add an exception in auto-mode-alist to specify "^bb.edn$" files in particular to be opened in clojure-mode, for code-like indentation and cider-eval support.
Environment & Version information
clojure-mode version
clojure-mode (version 5.16.0)
Emacs version
29.0.91
Operating system
macOS 12.5.1