This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (17)
- # calva (1)
- # clara (1)
- # cljs-dev (12)
- # clojure (151)
- # clojure-france (11)
- # clojure-uk (6)
- # conjure (4)
- # crux (1)
- # 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)
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?
(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
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
I heavily rely on fugitive's ability to put diffs directly onto the git index. Occasionally I write all new code into a commit before overwriting it, in order to provide a simpler progression.