why not run paren mode when that happens?

I’m not sure I can. Those modifications are done on the AST, which is built over the text document. So the symbol for the name will be replaced in the AST, which will be synced back to the text document by magic. I don’t think I can intercept that at that point.

Besides, I’d have to ensure that I caught all possible operations which might make non-local edits which would break the code in this way.

true, it has many implications. i’m not familiar with intellij

with their API that is

sucks if they don’t give you some kind of hook after the renaming action happens

They do, but it’s all based around the AST.

IntelliJ in general is not designed around non-local text-based manipulation, which has made getting parinfer in very hard.

So I’m interested what everyone thinks. In noctuid’s article, he argues basically (ignoring all the Emacs stuff) that a combination of auto-indentation and then an action which will indent and rebalance the parens will get most of parinfer’s advantages with none of the disadvantages. What does everyone think about this?

You miss the sort-of automatic paredit, but from shaunlebron's comment above it looks like that may not work as well as hoped due to the issues snoe has raised.

This means that the modifications are local rather than global, but I’m actually starting to think that that is an advantage.

It does not require running paren mode over the whole doc on file open, which has made this a non-starter for several people that I’ve seen.

Assuming the auto-indentation works correctly, I’m actually inclined to agree with him. I’m interested in feedback or counter arguments

In fact, it has one big advantage over parinfer - it doesn’t require mode switching, but provides the main things that users seem to want from both modes (auto-indent from paren mode, and rebalancing based on indentation from indent mode).

few points here:

1. yeah, it’s sad to see the auto-paredit stuff crumbling

it remains true in some cases, obviously, but it’s certainly broken in enough cases that it can’t be advertised like that anymore

Yeah. I’m interested whether people using parinfer a lot actually use that. It always seemed to me like it doesn’t offer enough control - I don’t usually slurp or barf to the end of the line.

But again, I may not have used it enough.

From my POV, the hypothetical mode above has another huge advantage - it works much better with IntelliJ’s model.

It’s still quite a lot of work, but removes a lot of the edge cases.

2. the aggressive-indent + rebalance action based on indentation is another idea that will have tradeoffs that noctuid mentions

in the absence of modes, we must deduce user intention about what is to be preserved by the action the user is taking

there are multiple actions that make this tricky

tab/shift-tab can be wrapped to convey ‘rebalance based on indentation'

spacebar and backspace though?

Right, that was what I was thinking.

or pasting spaces

pasting code containing indentation

But pasting code containing indentation doesn’t work correctly with indent mode either.

AFAIK

it must work in Indent Mode because transformation is based on text not user action

however the text gets there, it will be transformed

Only if you’re pasting code with the caret at the start of the line.

full file transformation, unless the parent expression hack is used

If you’re pasting code after a bunch of spaces, which is pretty common, it won’t work.

http://shaunlebron.github.io/parinfer/demo

sorry, never made this share snippets, but I think it’d be constructive to produce an example here

Ok, let me see if I can come up with one

I think you may be talking about the extra indentation of the first line

I’m referring to the fact that the indentation is parsed no matter how it gets there

What I mean is:

(let [x 10])

I’ve just closed the square brace, and I press enter, then I paste:

(when true
  (do-something))

That code gets broken. I mean, I understand why it happens, but it’s a very common case that will confuse users.

right, okay

I have the additional problem I discussed above, where non-local changes like renames will currently break things badly.

so in the case of pasting this in this new hypothetical mode, it would be pasted, then aggressively indented

Yeah, Cursive actually already does that - newly pasted code gets reformatted.

how would you handle backspacing indentation

It probably would not be allowed, thinking about it - you’d have to dedent

I imagine aggressive indent would stop the cursor at the indentation threshold, similar to paren mode

Right.

I guess I’m just starting to get the feeling that indentation is actually more fragile than I had assumed.

Especially at transitional points while editing.

And I’m starting to think that perhaps changing parens around based on indentation should be the explicit action, not the automatic one.

I think it’s worth trying

If only because the refactoring problem I describe above is probably a deal-breaker for me.

we can hypothesize about new users, but we gotta build both and see how they respond

Definitely.

obviously, do what’s best for your sanity in Cursive especially

you’ve been battling terrible corner cases on that for a while

Yeah, it’s been painful.

(sorry to be the source of that…)

Ok, I’m going to patch this up for now, and then I think I’m going to try to implement hypothetical mode X for a test release that people can try out.

No worries, it’s all been very interesting.

Even if nothing else comes of it, having provoked people to think about it is really valuable.

marking off dead ends is still science I suppose

Hehe, definitely, although I wouldn’t say we’re at the point of marking off parinfer just yet.

haha, well if it comes to that

Think of it as just losing some theoretical purity

As the edge cases come out.

I think the issue I raised about tab stops is part of this too. In indent mode, if you are changing the indentation it means you want to change the structure of the code, that can be done imprecisely with spaces or tabs or rebinding tab to paredit slurp or barf. I needed to highlight cursor column to work in indent mode effectively but even then it's so easy to indent one off in, say, long hiccup forms that the number of mistakes i made was always relatively high in the five months i used it. so I've come around to thinking that the paredit functions really do capture structural edits well.

In vim though, paredit or vimsexp, both have insert mappings that keep parens balanced. Parinfer's behavior when typing open or close parens, or removing them is however far better than vims paredit wrap, or indent mappings and I think slightly better than emacs'

@snoe: Yes, I definitely think that indent mode should snap to the right possible locations - that’s a change I’m planning to make tomorrow.