Dedicated lightweight edn-mode?

[yuhan0]

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

[bbatsov]

I agree with the points you've made. PR welcome!

On Sun, May 21, 2023, at 10:07 AM, yuhan0 wrote: Expected behavior EDN <https://github.com/edn-format/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 <#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 — Reply to this email directly, view it on GitHub <#650>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAZLSUJDPRV73CBOZHYZNLXHHEKLANCNFSM6AAAAAAYJHWYTQ>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>