Clojurians Log v2

@cfleming what’s up? 🙂

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

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

i was looking at that very case

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

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.

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

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

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

Previously, onUnmatchedCloseParen would have just deleted the close paren.

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

Hmm

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.

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

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

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

That seems to work:

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++;
      }
    }

Unfortunately it broke some other clamping cases:

(def b [[c d] |])

(let [a 1]|)
  ret)

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

@shaunlebron Any ideas?

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

Ok np

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

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

atom-pariner v1.19.0 is available!

Thanks Shaun for doing most of the hard work 😉

smartMode is available via Settings. Off by default.

I just downloaded it, gonna check it out now

oh, is the file-extensions config setting new?

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

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

Feels like it’s getting close though.

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

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

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

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

btw, atom 1.19 gives a deprecation error on parinfer 1.19

I'll report the issue

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

i’ll try to look over it today

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

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

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

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

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

in settings.cson find packagesWithKeymapsDisabled

where is the settings.cson file?

er, sorry , config.cson

in .atom

you can choose "Open Config" from the Atom menu

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

interesting, thanks!

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

nope, there it is again

it comes and goes when it wants apparently

actually, i think it reappeared after I updated to 1.19.2

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

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

it's not reloadable the way Emacs is

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

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

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

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