parinfer

tianshu 2017-07-19T05:23:32.144796Z

I don't think you should allow

(defn foo
 [a b]
   bar
   baz)
this is harmful.

tianshu 2017-07-19T05:26:39.175163Z

In most editor, you can use a shortcut to pull [a b] up.

tianshu 2017-07-19T05:33:39.244846Z

personally, I prefer there's no intermediate state, and no warning at all. so we can save file at any time, and never stop for reading the warning. It's not necessary to do all things without any editor built-in command, for people who ask "why I can't pull function argument vector up by just press backspace in VIM?", we can tell him "you can achieve this with J, it's faster and better".

shaunlebron 2017-07-19T06:02:17.546687Z

I think I understand your view here. There is some precedent with allowing intermediate states depending on cursor position:

(foo [a b]|
      bar)
Likewise, this new rule would do the same thing if the cursor is to the left of the open-paren:
(foo |[a b]
       bar)

shaunlebron 2017-07-19T06:04:33.572357Z

the warning is only intended to give plugin authors the ability to provide some affordance that the paren may be displaced in both circumstances above. (optional to show at all, but maybe these precarious parens should be highlighted yellow)

shaunlebron 2017-07-19T06:08:30.617361Z

> It’s not necessary to do all things without any editor built-in command I agree. I just want to allow the most basic operations without hotkeys, as long as simple solutions are available. since this intermediate state solution seems to apply principles already found in Parinfer’s design, I’m going to see what it looks like

shaunlebron 2017-07-19T06:09:34.629545Z

> so we can save file at any time you can still save a file in an intermediate state. Paren Mode will correct indentation before opening.

shaunlebron 2017-07-19T06:13:23.673371Z

early version of 3.3.0 is unpublished but playable in demo: http://shaunlebron.github.io/parinfer/demo

shaunlebron 2017-07-19T06:13:53.678953Z

will be looking at indentation correction after cursor movement next

shaunlebron 2017-07-19T06:18:59.738344Z

The swallowing of the bar line at the end is what I’m trying to fix now

cfleming 2017-07-19T07:37:26.939477Z

@shaunlebron I’m having problems getting my port to work correctly.

cfleming 2017-07-19T07:37:50.946757Z

I think the issue is that there’s now a distinction between result.x and result.inputX

cfleming 2017-07-19T07:38:05.951286Z

And result.lineNo and result.inputLineNo.

cfleming 2017-07-19T07:38:26.957515Z

What’s the difference between those values? When do they differ?

cfleming 2017-07-19T07:39:01.967931Z

The previous version my port was based on didn’t have that distinction.

shaunlebron 2017-07-19T13:24:41.439706Z

input coords vs output coords

shaunlebron 2017-07-19T13:25:45.473232Z

right now since there are no lines added or removed, result.inputLineNo and result.lineNo will always be the same

shaunlebron 2017-07-19T13:27:36.532037Z

but obviously things can change within a line—like indentation and parens—so result.inputX allows us to keep track of the original position of the current character being scanned

shaunlebron 2017-07-19T13:29:04.579148Z

I use input coords when reporting errors since errors result in the original unmodified text being returned, and we don’t want to report the error position in terms of the new output text that was thrown away

shaunlebron 2017-07-19T13:31:47.670186Z

I also use them to prevent problems with changes, since subsequent change positions could be affected by previous ones.

shaunlebron 2017-07-19T13:35:46.801464Z

lemme know if I can help look at the port

shaunlebron 2017-07-19T17:53:26.377081Z

just published 3.3.0 with smartMode to keep this experimental stuff out of original indent mode

shaunlebron 2017-07-19T17:54:30.414912Z

the demo page defaults to smartMode, and re-exposes the other modes again for comparison: http://shaunlebron.github.io/parinfer/demo