Clojurians Log v2

Here’s a WIP of what this looks like in Cursive now.

It never runs paren mode automatically, because of: https://github.com/shaunlebron/parinfer/wiki/Problems-integrating-parinfer-into-Cursive

I made some trivial modifications to paren mode, so that it now returns where in the doc the indentation is incorrect, and I can now mark this in the editor:

The markers get a tooltip explaining what’s going on:

If the user modifies the document, they’ll be notified that parinfer cannot be applied:

I don’t notify on caret movement even though parinfer can’t be applied then either, it’s a little intrusive.

It’s possible this is stockholm syndrome since I can’t do anything else, but I actually like this better than automatically running paren mode.

Here’s what I’m planning to do to improve this.

The paren mode indentation check can also be trivially made to return the extents of all the top-level forms in the document, and also to record whether each top-level form is correctly indented or not.

After these recent changes, parinfer is only run in response to a change or caret movement.

So when I come to run it, I will have: 1. a list of changes and where in the doc they happened, 2. a list of top-level forms and whether they’re correctly indented or not.

I can then run parinfer just over the top-level forms which are correctly indented, and which intersect with a change (i.e. the user made a modification within that form).

If any of the changes intersect top-level forms which cannot have parinfer run over them because their indentation is inconsistent, the user will get an error as above and parinfer will not run.

It’s an open question whether I should run partially, i.e. process the top-level forms which are correctly indented even if some are not - I’ll need to try that.

This has some really nice properties:

1. Files are never modified just by looking at them, which is disturbing for many users (and me).

2. Parinfer will only be applied locally, so it will only make changes in the region of the file the user is modifying, and only when the user actually makes changes and is presumably looking to see what happened.

3. Even if a file is inconsistently indented, as long as the section of the file the user wants to work on is consistent, there’s no problem. The other section of the file will not be touched, and parinfer will work where the user is working.

4. There’s no need for parlinter or anything similar, which should make adoption in mixed teams much easier.

There are a few details to work out, but I think this is a really nice model.

The integration is somewhat IntelliJ specific, but I think this should be relatively easy to integrate into any editor which supports markers like the above in the editor.

One more screenshot - if the line is incorrectly dedented and there’s no whitespace at the line start, the first char is marked:

@cfleming: wow, this is great!

will you mark other things that paren mode corrects? paren trails

No, the important thing I want to communicate to the user is what they need to fix to get the doc into a valid state.

That’s only indentation, really.

Then they can fix it by hand, or reformat the doc, or whatever.

so close-parens at the start of a line will be moved when a file is opened, as long as the indentation is fine?

No, but close parens at the start of a line wouldn’t prevent parinfer from running, right? They’ll just get tidied up when it does.

I guess that will cause paren mode to run, so I could detect that case in order to just go ahead and run paren mode rather than smart mode, but it’s not something the user should have to think about.

I’m not sure what “prevent parinfer from running” means

incorrect indentation doesn’t prevent parinfer from running, so if you mean “cause parinfer to perform structural changes”, then I suppose it’s okay to ignore paren movement

but this does violate your first property “1. Files are never modified just by looking at them”

You’re right that it doesn’t prevent parinfer from running, but it does prevent me from running it without breaking people’s code which is the problem I’m actually trying to solve.

I’m not sure I understand - why would that violate the first property? That just says that a file will never be modified simply by opening it, which is very surprising to users right now.