@lee I ran into an edge case between coercing a node from a string and parsing a node from a string expression.

user=> (require '[rewrite-clj.node :as n])
nil
user=> (n/coerce "foo")
<token: "foo">
user=> (keys (n/coerce "foo"))
(:value :string-value)
;;; vs
user=> (require '[rewrite-clj.parser :as p])
nil
user=> (def node (p/parse-string (pr-str "foo")))
#'user/node
user=> node
<token: "foo">
user=> (keys node)
(:lines)

Do you think it would be good to fix this? I'll first try it in clj-kondo's fork

The correct fix might be this:

(extend-protocol NodeCoerceable
  String
  (coerce [v]
    (string-node/string-node v)))

I'll do a PR later, if I don't detect any issues with clj-kondo

Yeah, there is this issue again, related to what we had earlier:

user=> (node/coerce "\\s")
<token: "\s">
user=> (node/sexpr (node/coerce "\\s"))
Execution error (ExceptionInfo) at clj-kondo.impl.toolsreader.v1v2v2.clojure.tools.reader.impl.errors/throw-ex (errors.clj:26).
Unsupported escape character: \s.

This weirdness may be introduced by read-string-data. I wonder why rewrite-clj has its own string parsing function, since for the rest of the tokens it just reads the next EDN "token"

@lee I have a preliminary fix here: https://github.com/clj-kondo/clj-kondo/commit/a4c5baea66f4a5f4b9831807d75289930b14f34a I feel like rewrite-clj is adding some unnecessary complexity in this area, but I'm working around it by using the same parsing strategy during coercion as during parsing