Parinfer can break code on symbol rename refactoring by prematurely removing spaces

[gnl]

Here's the code I just encountered this with:

(s/defn compatible-units :- [sc/Unit]
  [quantity :- sc/Quantity
   all-units :- s/Bool]
  (if (not all-units)
.....

Trying to rename all-units to something in parinfer mode removes the space after not:

(if (notsomething)

[vincent-dm]

I also experience this problem: find&replace changes the indentation, which causes parinfer to mess things up. This is quite dangerous.

(I hope @cursive-ide won't regret having implemented Parinfer. Despite all the tons of work and rework it has cost, it has been the feature that got me on board with Cursive. I'm now sharpening my skills and will buy a licence when I start using it for projects within a few weeks.)

[cursive-ghost]

So there are two different problems here. @vincent-dm I think you're talking about something more like #1327 - he's modifying the indentation by typing, but using find & replace is much more susceptible to that problem. Note that Cursive will handle that if you use the rename refactoring rather than find & replace. Other than that, that's just an unfortunate side effect of how parinfer works.

@gnl yours looks like a bug, I'll try to reproduce. Are you using the rename refactoring when this happens?

[cursive-ghost]

Oh, and don't worry @vincent-dm, no regrets about implementing parinfer, although it's been much harder than I expected. I'm planning to create a hybrid mode similar to parinfer that I believe will work better and will avoid a lot of these problems.

[gnl]

@cursive-ide - yup, I'm using symbol rename refactoring (not a simple search&replace).

[Engelberg]

My understanding is that Parinfer is supposed to have both an "indent mode" and a "paren mode", and it should be easy to toggle between the two.

Related to this issue, I keep running into situations where ordinary additions will totally destroy the semantics of the following code.

For me, a common case is:

(my-function {:a 1,
              :b 2})

and then I'll start typing a new parameter between my-function and the left curly brace {. The second line :b 2 ends up "falling out" of the map. What I want is for the second line to get carried along with the first line.

So either Cursive should implement "paren mode" and an easy way to toggle (because paren mode does the right thing and pushes the second line along) or Cursive should be more intelligent than standard parinfer for cases like this.

[gnl]

@Engelberg yes, the case you described is another reason why I mostly stay in paredit mode for now, just using parinfer for occasional cleanup in between.

On a side note, this might be useful to someone - I'm using an IdeaVIM mapping in my ~/.ideavimrc to quickly infer parens without manually cycling modes:

noremap <Space>rp :action :cursive.actions.paredit/toggle<CR>:action :cursive.actions.paredit/toggle<CR>kj:action :cursive.actions.paredit/toggle<CR>:action ReformatCode<CR>

By automatically cycling through all modes it also briefly switches to parinfer and moves a line up and down forcing a single inference and then returning to paredit mode.

[cursive-ghost]

@gnl That's pretty cool, thanks - there's actually a new doc showing how to customise IdeaVim here, would you mind adding that over there?

[cursive-ghost]

@Engelberg Yes, that problem is described over at #1327. It's a problem that doesn't really have a good solution using vanilla parinfer. Paren mode isn't really designed for editing since it doesn't have the semantic knowledge to correctly indent, for example it doesn't know the difference between:

(defn x []
  (foo))

and

(println a
         b
         c)

Basically, paren mode is primarily for ensuring that the document conforms to the invariants that indent mode requires.

I'm actually planning to develop a hybrid mode shortly, which in my head at least provides the best of both worlds. I've been discussing it with Shaun in the Parinfer Slack chat. I'll have some EAP releases to test it out when it's ready.

[gnl]

@cursive-ide Done!

[cursive-ghost]

@gnl I can't reproduce your original issue - renaming all-units works fine for me. Here's the exact code I used:

(ns cursive-1359.core
  (:require [schema.core :as s]))

(s/defn compatible-units :- [sc/Unit]
  [quantity :- sc/Quantity
   all-units :- s/Bool]
  (if (not all-units)
    all-units))

I can rename there from either of the usages and the definition, and it works correctly.

[gnl]

@cursive-ide I just reproduced it again with this code (had to do some modifications to be able to resolve all the symbols:

(ns unit-scan.test-parinf
  (:require [schema.core :as s :include-macros true]
            [unit-scan.schema :as sc]))

(s/defn compatible-units :- [sc/Unit]
  [quantity :- sc/Quantity
   all-units :- s/Bool]
  (if (not all-units)
    all-units))

A couple important points:

• it only seems to happen with inline refactoring and when the whole string is deleted before the new one is entered.
  p.ex. when I rename vars after initiating the inline rename refactoring I often will do cW in IdeaVIM, which gives me an empty string and lets me enter the new name. It seems that moment of "emptiness" prompts parinfer to reinfer (but only after the rename is confirmed with enter)
• I'm writing ClojureScript (although I'm guessing it shouldn't matter)

[cursive-ghost]

So I still can't reproduce this. I suspect it's something funky that IdeaVim is doing. I've installed it, here's what I'm trying.
I have my cursor here, in normal mode:

I invoke the refactoring:

Then I use cW:

That drops me into insert mode but seems to stop the refactoring process. Am I making some IdeaVim newbie mistake? Or have you customised IdeaVim in some way that might cause this?

[gnl]

Ok, picture > 1000 words situation here, I can see what we're doing differently now.

When I start the refactoring I'm here:

Then I hit cW:

This changes text to the next whitespace, so when you do it inside the parens it deletes the closing paren as well, I'm guessing that's aborting the refactoring process.

Then I start typing the new name and things get messed up:

This behaviour is actually a little different to what I observed initially (just the whitespace being removed), but it still seems to be caused by parinfer being a little overzealous here.

I'm also guessing it should behave similarly without IdeaVIM if you just start the refactoring process from the definition and delete everything in there before typing the new name, which it should do by default because the whole symbol is automatically selected.