This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-07-18
Channels
- # beginners (17)
- # calva (1)
- # clara (1)
- # cljs-dev (12)
- # clojure (151)
- # clojure-france (11)
- # clojure-uk (6)
- # conjure (4)
- # datomic (32)
- # duct (42)
- # emacs (2)
- # fulcro (20)
- # lambdaisland (4)
- # malli (5)
- # meander (32)
- # pathom (8)
- # reagent (1)
- # reitit (7)
- # shadow-cljs (2)
- # sql (6)
- # tools-deps (2)
- # vim (17)
- # xtdb (1)
I'm having an issue where parinfer deletes a closing bracket on a multi-arity function.
(defn get-input
"Waits for user to enter text and hit enter, then cleans the input"
([] (get-input nil))
([default
(let [input (clojure.string/trim (read-line))]
(if (empty? input)
default
(clojure.string/lower-case input)))]))
See where it is taking the closing bracket after default
and putting it on the last line?
When I manually insert it back in, parinfer deletes it as soon as I move my cursor off the line. How do I go about preventing this behavior?
shouldn't the (let
be moved to the left one space?
(I don't know re: parinfer, my sole experience with it is working on a team where one dev randomly indented things wrongly, and another dev "let" parinfer move parens based on the other dev's indentation
between two juniors, they managed to break things very badly...
You are correct. That's what I get for copy pasting. Thank you. Yeah, I'm sure parinfer has some quirks like this that would make it hard in a team environment. I'm a solo dev though and mostly prefer it over the paredits of the world.
with copy/paste I would have thought PASTE mode would prevent parinfer breaking things
FWIW, i use parinfer and work on a team of people who don't, and it's been working out fine
it's useful to be able to selectively check in lines/chunks of code instead of the whole file, via git add --patch
or something like magit (i use vimagit)
because sometimes, parinfer's choice of indentation can be wildly different from the team's, and it can be annoying to check in a bunch of changes that are mostly just whitespace changes
on the other hand, though, on my team, we're used to reviewing diffs with whitespace-only changes hidden, so it isn't a huge problem when i do occasionally check in a bunch of whitespace/indentation fixes
@dave agreed, at this point git add -p
then git diff --cached
and git rebase -i origin/master
are my set of prayers, always invoked meticulously in that order
(with a commit before rebase of course)
also, git log -p
to find out what's up with the repo I'm merging to