Fork me on GitHub
#vim
<
2020-07-18
>
Chase15:07:51

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)))])) 

Chase15:07:14

See where it is taking the closing bracket after default and putting it on the last line?

Chase15:07:47

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?

noisesmith16:07:13

shouldn't the (let be moved to the left one space?

noisesmith16:07:00

(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

noisesmith16:07:20

between two juniors, they managed to break things very badly...

Chase16:07:42

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.

noisesmith16:07:51

with copy/paste I would have thought PASTE mode would prevent parinfer breaking things

dave17:07:01

FWIW, i use parinfer and work on a team of people who don't, and it's been working out fine

dave17:07:53

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)

dave17:07:27

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

dave17:07:05

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

noisesmith18:07:46

@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

noisesmith18:07:06

(with a commit before rebase of course)

noisesmith18:07:32

also, git log -p to find out what's up with the repo I'm merging to

dominicm20:07:08

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.

nate23:07:14

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...

👍 1