Fork me on GitHub
#parinfer
<
2017-08-08
>
cfleming00:08:09

So I’m debugging this case here: (foo}}}}|)

cfleming00:08:52

Here’s what’s going on: the paren trail is correctly initialised to 4-9, which covers all the closing parens, including mismatched.

shaunlebron00:08:07

i was looking at that very case

shaunlebron00:08:30

it was strangely fixed by removing === NEWLINE from isWhitespace

cfleming00:08:24

But clampParenTrailToCursor seems to be doing the wrong thing. It clamps the paren trail to 8-9, which is right, but then it scans over 4-8 and removes 4 items from parenTrail.openers, even though those are unmatched.

cfleming00:08:01

There’s only one item in openers, since there’s only one open paren, so what happens is the output is (foo| instead of (foo|)

cfleming00:08:33

Hmm, I had to add NEWLINE to isWhitespace, but I can’t remember why now.

cfleming00:08:50

I bet I know what’s happening - I couldn’t figure out how this ever used to work.

cfleming00:08:10

Previously, onUnmatchedCloseParen would have just deleted the close paren.

cfleming00:08:48

So clampParenTrailToCursor would have received a paren trail of 4-5, clamped it to 4-5 and not removed anything.

cfleming00:08:58

I’m not sure how to handle that - if the unmatched parens aren’t deleted immediately, I’m not sure how to track which are matched and which are not.

cfleming00:08:47

I don’t think the paren trail start can be moved, since matched and unmatched might be mixed: ((foo)})

cfleming00:08:48

I think that when cPTTC sees a close paren, it should only remove one from openers if they match.

cfleming00:08:50

i.e. we should be able to use the openers stack to tell if the closing parens are matched or not.

cfleming00:08:37

That seems to work:

cfleming00:08:40

for (i = result.lineStart + startX; i < result.lineStart + newStartX; i++) {
      var ch = text[i];
      if (isCloseParen(ch) && MATCH_PAREN[peek(openers, removeCount).ch] === ch) {
        removeCount++;
      }
    }

cfleming00:08:35

Unfortunately it broke some other clamping cases:

cfleming00:08:41

(def b [[c d] |])

cfleming00:08:14

(let [a 1]|)
  ret)

cfleming00:08:37

I guess that’s not sufficient to know if the paren is actually unmatched or not.

shaunlebron00:08:39

@cfleming: sorry i’m not able to think this far into the weeds on this issue right now

cfleming02:08:24

@shaunlebron I’ve pushed some changes, all indent mode tests now work except for that clamping one above.

cfleming02:08:42

I’m going to start on paren & smart mode now.

chrisoakman04:08:08

atom-pariner v1.19.0 is available!

chrisoakman04:08:33

Thanks Shaun for doing most of the hard work 😉

chrisoakman04:08:07

smartMode is available via Settings. Off by default.

mattly04:08:50

I just downloaded it, gonna check it out now

mattly04:08:58

oh, is the file-extensions config setting new?

chrisoakman04:08:45

It used to be in a file in your home directory. Moved to Atom Settings in this version.

cfleming04:08:57

@shaunlebron Ok, pushed some more fixes. There’s now the one failing case in indent mode, and 3 in paren mode. I haven’t looked at smart mode yet.

cfleming04:08:48

Feels like it’s getting close though.

shaunlebron05:08:13

@cfleming: thanks! sorry I couldn’t look today, will try again tomorrow

cfleming05:08:37

@shaunlebron No problem, if not I’m hopeful I can finish it up.

tianshu06:08:53

It's likely there's a bug if I insert a pair of parens, then delete the open paren.

rgdelato17:08:55

Upgraded my Parinfer Atom plugin on another machine, the switch from "Parinfer" to "parinfer" went completely smoothly, great job! 😄

mattly17:08:04

btw, atom 1.19 gives a deprecation error on parinfer 1.19

mattly17:08:23

I'll report the issue

shaunlebron20:08:13

damn, atom gets an upgrade the day after we finally release this beta http://blog.atom.io/2017/08/08/atom-1-19.html

shaunlebron20:08:23

i’ll try to look over it today

shaunlebron20:08:33

anyone know how to restore a package’s default hotkeys in atom?

shaunlebron20:08:30

I lost all my parinfer hotkeys when I clicked on a weird hotkey checkbox menu in parinfer settings

mattly20:08:54

you should be able to click it again to bring it back

shaunlebron20:08:55

i have only seen it appear there once, and I haven’t seen it since

mattly20:08:19

there's a listing in settings.cson, 1m

mattly20:08:59

in settings.cson find packagesWithKeymapsDisabled

shaunlebron20:08:33

where is the settings.cson file?

mattly20:08:52

er, sorry , config.cson

mattly20:08:02

you can choose "Open Config" from the Atom menu

mattly20:08:58

or bring up the command palette (Cmd-Shift-P on mac) and look for "Application: Open Your Config"

shaunlebron20:08:58

interesting, thanks!

shaunlebron20:08:30

i still don’t see the hotkey section in parinfer settings, but my hotkeys are back

shaunlebron20:08:33

nope, there it is again

shaunlebron20:08:51

it comes and goes when it wants apparently

shaunlebron20:08:18

actually, i think it reappeared after I updated to 1.19.2

mattly20:08:24

I really like working with the new parinfer btw, thanks!

mattly20:08:47

I haven't been using Atom for long, but I've noticed some oddities with it around updating stuff

mattly20:08:57

it's not reloadable the way Emacs is

mattly20:08:46

typically if I make major changes to my init file or change which packages are installed I'll just restart Atom, it seems to be more stable that way

shaunlebron20:08:28

thanks for feedback/reporting/config advice @mattly! atom does seem to need restarting from time to time

shaunlebron20:08:19

i’m working on a smaller page to demonstrate new features, so we can get feedback on smart mode stuff

shaunlebron20:08:58

that should get folks to try the new stuff, and we can wait to see if the implementation is stable enough before porting