This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (1)
- # babashka (5)
- # beginners (44)
- # calva (45)
- # cider (8)
- # clj-kondo (9)
- # cljdoc (12)
- # clojars (7)
- # clojure (20)
- # clojure-czech (1)
- # clojure-dev (26)
- # clojure-europe (24)
- # clojure-france (8)
- # clojure-uk (1)
- # clojurescript (12)
- # conjure (8)
- # datascript (10)
- # fulcro (7)
- # leiningen (2)
- # malli (19)
- # meander (5)
- # off-topic (113)
- # pathom (3)
- # precept (4)
- # re-frame (13)
- # reagent (19)
- # reitit (3)
- # rewrite-clj (69)
- # shadow-cljs (9)
- # spacemacs (16)
- # tools-deps (1)
- # vim (1)
- # xtdb (10)
parcera doesn't have an existing layer that i know of, but round-tripping is an explicit goal so iiuc it does the preservation thing pretty well. i have used it for something where those things were important.
on a possibly relatede note, there is this interesting paragraph in the instaparse readme: > I find the hiccup format to be pleasant and compact, especially when working with the parsed output in the REPL. The main advantage of the enlive format is that it allows you to use the very powerful enlive library to select and transform nodes in your tree. https://github.com/Engelberg/instaparse#output-format
the reason i mention that is the so-called enlive format and the select / transform stuff.
it's a todo-ish thing, but iiuc, hiccup can be converted to enlive format (and i presume the reverse is possible too).
someone in #off-topic suggested tools.reader could be patched to return ordered maps. I think I could support that in edamame, and just ignore whitespace/comments
the use case is config files for glam (package manager): glam itself and the user should both be able to write to the config file
but I don't want to depend on the funky default ordering of clojure maps to write back
not sure i followed whether you were or were not going to try to support comment preservation.
ah i see. i hope that if you do, you would eventually consider trying to support comments. i was going to say i really dislike not being able to put comments in package.json 😛
yeah, much discussion like this: https://stackoverflow.com/questions/244777/can-comments-be-used-in-json
One other solution I was considering: have one user.edn config and one machine.edn config and one config.edn which is the merged one of those two
(lib/assoc node :b 1)
(map-node ... children with child :b replaced with (token-node 1))
the use case would be merging EDN files while preserving formatting. edn-something could also work
@lee hmm, when I make a zipper of a map-node and then do z/root, I get back a forms node.
today I learned about node/coerce... I should probably include that in the clj-kondo hooks API. why hasn't anyone asked for this before :)
automatic coercion of metadata to metadata nodes is what caused me some grief when working with sci.
Fully qualify dep symbols in deps.edn: https://github.com/borkdude/rewrite-edn#examples