@cfleming interesting, smart mode should handle that well, but again it’s probably the editor integration that isn’t notifying parinfer of the nature of the change to help it do the right thing

I don’t think it’s that, it’s that IntelliJ sometimes produces very complex lists of overlapping changes.

ah, that’s actually what I meant

i’ll have to talk about state of parinfer on sunday for the repl podcast, maybe we can catch up on how it’s been working in cursive before then?

We’ve talked about this before, and IIRC the conclusion at the time was “it can’t be expected to handle all the potential edge cases for changes like that”, which I think is reasonable.

Sure, that sounds good.

i caught up with chris (atom) and jason (vim/kakoune) and they said the exact same thing about the editor integrations they’re maintaining

resorting to diffs for the changes they need

but only a partial solution

So what really made the difference was the change I made which doesn’t run paren mode on file open, but marks the problems instead and lets the user fix them.

Then it doesn’t matter if parinfer breaks something in a really crazy change list because the user can then fix it to what they meant.

because the breaking change is isolated to a single function?

No, a change may span various functions.

But at least it’s clearly marked where the problems are.

i suppose there’s different kinds of problems to think about

but you’re marking incorrect indentation

and not running indent/smart mode there

other problems are related to unexpected changes to code with previously correct indentation

Currently I don’t run it anywhere, so if the file is broken it’s broken, and there’s no parinfer until it’s fixed. I was planning to make a change to have that apply per top-level form, but I never got around to it and no-one has complained that it’s a problem.

i see, yeah i assumed the top-level form isolation was part of it

is smart mode on by default?

and are many using it?

and how’s the feedback?

(smart mode hidden by flag in atom, but feedback has been nil)

It’s actually not on by default, I meant to turn it on by default once it stabilised but never did. When I first brought it out a lot of people said they were using it and liking it, and I see occasional comments along those lines.

I don’t do any tracking though so I don’t have any firm numbers.

interesting, i suppose silence can be interpreted either way there

alright, I think that’s all I need to know for giving an update

thanks for pinging me on this

Generally, I’m super happy with it, and I use it all day myself.

The integration was one of the most painful things I’ve done in Cursive, though.

lein will always take top spot there, but this was probably second.

haha, alright, i expected as much, i remember how that was going last year

that might’ve been two years ago, idk anymore

A year or so, I think.

copy/paste?

is that a common thing, and is that alright in parinfer?

Copy/paste is still a little painful sometimes. I have plans to make it better, but haven’t had time.

It’s definitely a common thing, and mostly works ok.

It’s complicated by the fact that IntelliJ likes to auto-indent pasted blocks.

Which happens before parinfer gets to run. That occasionally leads to things you wouldn’t expect, but they’re generally easy issues to fix.

yeah, i had weird things happen when doing some cljs work in atom, like it would dedent entire expressions after my cursor that i had to manually fix

never isolated the cause, but the root of this is that it is very delicate to the wrong change information from the editor

I don’t think that’s always the cause, sometimes it makes sense if you think about it, but to a user who doesn’t understand the algorithm it’s going to be weird.

e.g. if your editor looks like this:

(defn foo [bar])
  |

there’s that, yeah

i.e. you’ve started a new function, and you want to paste the body

Pasting there in Cursive will result in:

(defn foo [bar])
(your pasted form)|

The user will have expected it to be inserted in the defn form, because their caret was indented when pasting. But IntelliJ pastes, then indents, and then at the end parinfer is run. The indent sees that the new block is outside the top-level form so it dedents it, and then parinfer doesn’t put it in because it’s no longer where the user thought they put it.

right, editor interference

@eraserhd how do i pronounce your last name? just wanna get that right

Right, but there’s no step there which is obviously wrong, but the end result is confusing.

@shaunlebron fuh-LEASE

btw, Kakoune apparently has almost exactly the change log we want, but it wasn't exposed. It wasn't the undo tree, but a monotonic change log that even records switches between branches of the undo tree.

Monotonic is probably the wrong word. Append-only. I will attempt to use it this week.

huh, interesting, i’d be interested to see how that plays out

e.g. i wonder if types of changes will have to be ignored or not

Well, there's two things to account for. The first is that this change log has only positional changes, not text. Internally, parinfer only needs positional changes, but it parses that out of text. So I'll need to change that somehow.

(I mean start and end line and column.)

The second is that parinfer wants changes as though they all happened simultaneously, and Kakoune's log has them stacked sequentially.

e.g. the log might say "insert 10 characters at position 2, then delete 3 at position 7"

so I'll need to flatten them

@shaunlebron About the state of integration. For Calva I have so far fallen back on only doing parinfer (smart mode) on the user’s command. Main reason being that vscode is a bit lacking in its API:s. But we have started a change in the whole formatting approach in Calva that might open up for on-the-fly parinfer.

or "squish" them, or whatever that operation should be called.

(But so far the users who have talked to me about it are happy with doing smart mode at will.)