Fork me on GitHub
#parinfer
<
2017-08-11
>
mattly04:08:08

as a user of parinfer in first emacs and now atom, the only time I switch to Paren mode is when I need to re-indent something because its place in the tree changed

mattly04:08:40

though I’ve found atom’s lisp-paredit easier to grok than emacs’s, and so I’m using raise/splice/etc more often

tianshu05:08:57

I can't get correct indentation on atom, I have lisp-paredit installed, but that not help. when I press enter, sometimes the indentation is correct, sometimes not.

rgdelato05:08:34

If you go into the lisp-paredit settings, you can set your list of indentation forms, maybe that will help?

rgdelato05:08:34

For example, if hello is in your indentation forms, then you get:

(hello :there
  |)
...and if it's not, then you get:
(hello :there
       |)

cfleming05:08:56

@mattly Is that true with smart mode as well, or with the current indent mode?

cfleming05:08:19

re: paren mode, that is.

rgdelato07:08:45

I guess I should clarify... that "unable to delete" issue is actually an issue with having forceBalance set to "off", so it's not a problem with Smart Mode exactly (and atom-parinfer has forceBalance set to "on" by default)

cfleming09:08:57

forceBalance is the new feature which flags an error when it finds an unmatched close paren instead of correcting it, is that right?

shaunlebron09:08:58

it’s a blanket option for a couple things

shaunlebron09:08:13

but when it’s on, you’re signaling that you want balanced parens no matter what

shaunlebron09:08:56

v2 dialed back the aggression on unmatched close-parens and leading close-parens

shaunlebron09:08:59

- unmatched close-parens are flagged rather than removed - leading close-parens are allowed by running Paren Mode when they are present

shaunlebron09:08:03

since both behaviors allow temporary imbalance, they are not used when forceBalance is enabled

shaunlebron09:08:48

for example, for leading close-parens:

(foo
  |) bar
if you reach the above state after pressing enter or deleting a word in Indent Mode, surprising things can happen

shaunlebron09:08:35

so the leading close-paren => Paren Mode behavior was the best I could come up with. and since Paren Mode allows imbalance, this behavior can’t be used with forceBalance

shaunlebron16:08:30

does that make sense?

shaunlebron16:08:19

leading close-paren => Paren Mode needed => possible imbalance => cannot use when forceBalanced

shaunlebron17:08:09

i’ll have to make a forceBalance section on the new page then

chrisoakman17:08:51

Or just remove it entirely 😉

shaunlebron17:08:58

if I removed it, I’d have to fork atom-parinfer 🙂

rgdelato17:08:27

So Shaun has asked this a few times in the GitHub issue... does anyone have a good idea about what should be the result if the user presses "delete" in this situation?

(def m {:a 1
        |} bar)

timgilbert17:08:59

I'd personally favor

(def m {:a 1|} bar)
...viewing delete as meaning "undo what I just typed"

timgilbert17:08:49

BTW, is there a 500-feet-up description of what the difference between smart mode and indent mode is (understanding that it's still a WIP) anywhere?

rgdelato17:08:51

My original guess is that maybe you'd end up like this:

(def m {:a 1
       |} bar)
...and then when you move your cursor away, you'd be reformatted to:
(def m {:a 1}
       bar)
...but honestly, I like Tim's idea if it pans out

rgdelato17:08:42

@timgilbert In my opinion, the biggest change is that expressions under you hold their shape: https://www.youtube.com/watch?v=9iZfdfsoC5o

timgilbert17:08:07

Thanks @rgdelato, will check that out

rgdelato17:08:28

so hopefully as a user, you'll never need to switch to Paren Mode anymore. From a more technical standpoint, Smart Mode takes a list of changes as well as the current state of the document to make decisions

shaunlebron19:08:56

Pressing delete twice might be surprising here if it joins the two lines, since it doesn’t constitute “undo what I typed”:

(def m {:a 1
        x|} bar)