@shaunlebron Depends on the form unfortunately. I guess that will only be an issue if renaming a symbol by deleting the whole thing - it would have to get down to 1 char wide for that to be an issue.

So I think I’m ok requiring some manual rearrangement in that case, since it’s likely to be far less common than other edits to leading forms - I think stickiness should be the default.

Again, my initial impression without having actually used it yet - still debugging the port, and haven’t had much time this last couple of days.

@shaunlebron IMO, when you want to edit some symbols, literals, etc, parens should never be changed. the indentation of bar, shouldn't affect the code struct.

I think what @shaunlebron means is if you have:

(println {:a 1
          :b 2}
   bar)

({:a 1
  :b 2}
 bar)

(println {:a 1
          :b 2}
         bar)

(println {:a 1
          :b 2}
 bar)

I think both is okay, but when I have

(println {:a 1
          :b 2}
         bar)

(print {:a 1
        :b 2
        bar})

it's likely a bug?

I agree that the current behavior should be changed to prevent surprising structure changes

thought about a minimal fix for this today. The problem happens when an open-paren moves backward. my first draft for a rule: when an open-paren moves backward, the next line should be moved backward by same amount only to prevent being newly absorbed into the list. applying this recursively for any subsequently shifted open-parens will prevent structure changes without worrying about sibling alignment, a la Paren Mode

pushing forms around sokoban-style is as minimal a method as I can think of right now. will need more time to understand what stickiness might do and how to implement it

a weird edge case:

(defn foo
  |[a b]
  bar
  baz)

1. with nudging:

(defn foo |[a b])
bar
  baz

2. with stickiness:

(defn foo |[a b])
bar
baz

(defn foo |[a b
            bar
            baz])

unfortunately, none of these three is what we want.

I will choose 3, because when I edit indentation, usually I wish I can change the structure. If I want to achieve

(defn foo |[a b]
  bar
  baz)

I will think about how to allow this intermediate state then:

(defn foo
|[a b]
   bar
   baz)

we would have to use the cursor position to deduce when to prevent the close-paren from moving, like it already does in this case:

(defn foo
 [a b]|
   bar
   baz)

structure can still change the moment you move the cursor to another line. (for example, in the original gif case—when deleting println and typing print, bar would still be absorbed by the map, unless it was indented by just two spaces)

so, a fourth option: 4. always hold paren-trail of cursor line:

(defn foo |[a b]
  bar
  baz)

I don’t think I can prevent structural damage in all cases, but I think I can prevent it for intermediate states—which seems most important

we could do either of the following extra things to improve the UX around this: a) return a warning for parens that would be displaced when cursor is moved to another line—so editors can highlight them b) apply Paren Mode to prevent paren-displacement when cursor is moved to another line—can be done if we pass in previous cursor position

made my thoughts a little more concrete here: https://github.com/shaunlebron/parinfer/issues/143#issuecomment-316125241