Clojurians Log v2

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

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.

I've been known to start up vim sessions just to use fugitive to inspect and stage. I keep meaning to try out vimagit, one of these days...