This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-04-26
Channels
- # aleph (5)
- # announcements (9)
- # beginners (115)
- # boot (36)
- # calva (13)
- # cider (4)
- # clara (7)
- # cljs-dev (27)
- # cljsrn (20)
- # clojure (182)
- # clojure-conj (3)
- # clojure-dev (4)
- # clojure-europe (3)
- # clojure-italy (2)
- # clojure-nl (4)
- # clojure-uk (34)
- # clojurebridge (3)
- # clojurescript (19)
- # clojureverse-ops (3)
- # core-typed (1)
- # cursive (12)
- # data-science (3)
- # datomic (16)
- # emacs (9)
- # events (5)
- # figwheel-main (11)
- # fulcro (14)
- # graphql (7)
- # jobs (10)
- # jobs-discuss (6)
- # lein-figwheel (8)
- # leiningen (2)
- # lumo (22)
- # mount (1)
- # nrepl (7)
- # off-topic (69)
- # overtone (17)
- # pathom (3)
- # quil (1)
- # re-frame (5)
- # reagent (23)
- # reitit (6)
- # remote-jobs (1)
- # rewrite-clj (4)
- # ring (38)
- # shadow-cljs (54)
- # sql (9)
- # uncomplicate (5)
- # xtdb (1)
@lee to explore this matter of behavior for out-of-bounds input, i've tried calling find-last-by-pos with some other values. here are some results (i'll repeat some of the set up as the previous values are not logged, but thanks to borkdude, the following should get logged). given:
(require '[rewrite-clj.zip :as rz])
(def a-form "(defn hi-fn\n [x]\n (+ x 1))")
it appears that:
(-> a-form (rz/of-string {:track-position? true}) (rz/find-last-by-pos [1 0]) rz/string)
returns nil, but:
(-> a-form (rz/of-string {:track-position? true}) (rz/find-last-by-pos [2 0]) rz/string)
(-> a-form (rz/of-string {:track-position? true}) (rz/find-last-by-pos [3 0]) rz/string)
return "\n".
possibly worth noting, along what you mentioned about returned values passed the end of the form:
(-> a-form (rz/of-string {:track-position? true}) (rz/find-last-by-pos [0 0]) rz/string)
(-> a-form (rz/of-string {:track-position? true}) (rz/find-last-by-pos [4 0]) rz/string)
return nil.
it also turns out that using -1 for the column value, yields the same results.
i find these return values to be surprising. if we think these are all the same type of situation, may be a single consistent return value makes more sense (e.g. nil) or possibly throwing an exception. not sure though.
btw, is the row, col info being 1-based instead of 0-based, documented any where? if it isn't, it seems like it would be worthwhile. wdyt?Thanks @sogaiu, I strongly agree that 1 based needs to be documented very clearly. When I was reviewing your examples, I did not remember it was 1 based and was scratching my head a bit. I’ll have a look at your other scenarios sometime soon, thanks very much for digging in.