Fork me on GitHub
#parinfer
<
2017-07-19
>
tianshu05:07:32

I don't think you should allow

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

tianshu05:07:39

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

tianshu05:07:39

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".

shaunlebron06:07:17

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)

shaunlebron06:07:33

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)

shaunlebron06:07:30

> 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

shaunlebron06:07:34

> 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.

shaunlebron06:07:23

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

shaunlebron06:07:53

will be looking at indentation correction after cursor movement next

shaunlebron06:07:59

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

cfleming07:07:26

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

cfleming07:07:50

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

cfleming07:07:05

And result.lineNo and result.inputLineNo.

cfleming07:07:26

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

cfleming07:07:01

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

shaunlebron13:07:41

input coords vs output coords

shaunlebron13:07:45

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

shaunlebron13:07:36

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

shaunlebron13:07:04

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

shaunlebron13:07:47

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

shaunlebron13:07:46

lemme know if I can help look at the port

shaunlebron17:07:26

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

shaunlebron17:07:30

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