Fork me on GitHub
#parinfer
<
2017-08-19
>
shaunlebron00:08:50

I misunderstood—you’re only applying the markers after a user modifies the document

shaunlebron00:08:04

and this solves your problem because you are now running paren mode after every edit? actually I’m still unsure how this solves your problem

shaunlebron00:08:39

Your new steps as I understand them: 1. On file open, parinfer is not used to do any processing. 2. On file edit, parinfer is only applied if indentation was correct prior to the edit. otherwise, mark the offending lines.

cfleming02:08:41

So the thing that makes all this possible that I only just figured out this week is that in a document modification listener I can’t modify the document contents, but I can add markers.

cfleming02:08:24

So briefly, the flow is this:

cfleming02:08:40

1. On file open, no processing is performed, correct.

cfleming02:08:54

2. The “bad indentation” markers are calculated and applied in an inspection, which runs on the background all the time. So they will always be visible when the user is in paredit mode, they’re not dependent on any particular stage of this process.

cfleming02:08:21

3. On first document edit, before the edit is applied I run my paren mode indentation check and record the results. I apply markers to the document corresponding to the edit, and record what the indent delta for that particular edit is.

cfleming02:08:40

4. When the series of edits (IntelliJ calls this a Command, basically an undoable group of edits) finishes, I check the indentation results from step 3. If the indentation was correct before the command started then I apply parinfer, otherwise I show the warning. The changes to pass to parinfer are calculated from the markers from step 2.

cfleming02:08:33

I have this all working now, and although I’ve only done rudimentary testing so far it seems to work fine.

cfleming02:08:49

This also happens based on caret movement, which works in a similar way.

cfleming05:08:02

So next week I’m going to try the top-level form improvement, and I also have to see if I can modify parinfer to handle multiple caret positions in a sensible way.

cfleming05:08:11

Basically, for each editor viewing a particular document, I’ll have a prevCursor and cursor position.

cfleming05:08:44

Once I have a working WIP I’ll put it somewhere so interested people can try it out.

cfleming08:08:00

Is it a true statement that caret movement can only affect how parinfer indents code/retains parens at the point the caret is moving from?

cfleming08:08:34

i.e. if I move the caret from some point in a document to another point, that will never affect the result at the destination point until the user starts editing there.

rgdelato08:08:07

I don't know if this is what you mean, but

(foo
  |)
will become
(foo|)
if you move your caret to the top line

cfleming09:08:03

Right, but that’s caused by the caret leaving line 2. So if you e.g. clicked in a totally different form, only the form the caret is leaving will be affected.

shaunlebron15:08:44

parinfer will suspend certain operations around forms that the cursor is touching

shaunlebron15:08:06

when the cursor leaves, the form is released

shaunlebron15:08:10

when the cursor enters a new form, the form is probably already normalized, so there are really no rules to suspend until something is edited

shaunlebron15:08:37

so I think it’s safe to assume your stated property is correct (i.e. cursor entering a new form will not modify it)

Aron20:08:10

anyone using neovim/linux?