Clojurians Log v2

@shaunlebron Awesome, thanks. I think I have the changes ported to my internal version of parinfer, I’ll get the tests over tomorrow and try them out.

@cfleming: you mean parinfer-jvm?

@shaunlebron My internal version has diverged from that somewhat.

I wanted to get the changes in there to actually try it out properly before I spent the time migrating to something that has no known actual clients 🙂

I’m also planning to write something that records the changes made while editing code, to get a better idea of how to calculate the changes array.

When a command creates overlapping changes, it’s actually difficult to know what to do.

I can’t seem to remember the overlapping changes example

I don’t think we’ve ever discussed one, but I believe when I initially investigated this idea I found that it was quite common.

I’m planning to log all the changes while editing some code to get a better idea of when it might happen.

Imagine that some command creates a change to some range of text, and then makes another change inside that range somewhere.

I suspect the current change dx accumulation might not work correctly there.

But I need to write some examples on a piece of paper to think it through.

interesting, having a hard time to imagining an example, let me know when your logs catch one!

I bet this could do it: https://twitter.com/CursiveIDE/status/879504166237818880

Depending on how the various sub-steps are implemented.

yikes

I’d be tempted to avoid that problem somehow

Cursive, after performing a paredit command, usually reformats the form. That could also create overlapping changes.

Got to go, will report back.

my gut is that when a change intersects another within the current batch, it should probably go into a new batch to run afterward