Fork me on GitHub

jumping into this convo late but regarding the nightcode/parinfer teaching feedback, i've heard similar things before. my own experience teaching clojure to dozens of students was that unassisted editing lead to a smorgasbord of unmatched delimiter errors, and paredit was a huge distraction to my lessons.


the biggest thing i learned after teaching was how philosophical it was. i was the lead java instructor across all iron yard campuses and i was surprised at how much people's teaching philosophy could differ.


one instructor was adamant that students shouldn't learn java with an IDE. he said the autocompletion and autoimporting were terrible for learning. i disagreed, arguing that typing imports and method names was not fundamental to programming. data structures, control flow, etc are fundamental; i'd rather focus on that.


another thing that is fundamental is scope, and the most important tool to visualizing it is indentation. i always annoyed my students when their indentation was wrong, b/c it prevented them from visualizing scope. parinfer fit my teaching pattern perfectly because i already was drilling them on good indentation.


i think teaching with parinfer requires a mental shift if you aren't already teaching that way. if your students aren't constantly thinking about indentation (and scope) the editing will lead to surprises. i think students should be constantly thinking about that anyway, but as i said teaching philosophies can differ 🙂


Thanks for sharing this @sekao. I'm a former The Iron Yard instructor too 🙂


I basically agree with everything you're saying re: teaching philosophies. One of the things I did in my class was get the students to use JavaScript Standard Style:


The before / after for that was awesome. It caught lots of little issues for them; helped them focus on the logic.


Which - like you said - I think is the important piece.


Fixing indentation was one of the more important things that adopting Standard helped my students with.


"another thing that is fundamental is scope, and the most important tool to visualizing it is indentation" --> 💯. Could not agree more about this.


@elenam can you share your thoughts on why parinfer was confusing for your classes?


my intuition is that indentation is natural because outside of programming languages, we still use indentation in bulleted lists:

1. mow the lawn
  a. rake leaves
  b. edge
  c. mow
  d. cleanup
    i. use blower
    ii. sweep the rest
2. paint the house
  a. tape the windows
  b. spray all walls
  c. paint trim by hand
3. buy a car
  a. test drive
  b. haggle
    i. mention bluebook price
    ii. don't be afraid to walk out
  c. drive home


maybe it can be taught by placing parens on this kind of list first


(1. mow the lawn
  (a. rake leaves)
  (b. edge)
  (c. mow)
  (d. cleanup
    (i. use blower)
    (ii. sweep the rest)))
(2. paint the house
  (a. tape the windows)
  (b. spray all walls)
  (c. paint trim by hand))
(3. buy a car
  (a. test drive)
  (b. haggle
    (i. mention bluebook price)
    (ii. don't be afraid to walk out))
  (c. drive home))


as an aside, I'm also curious if v3 would make a significant difference in teaching beginners since there's less unexpected behavior


@shaunlebron parinfer smart mode seems to get a bit confused if you do certain editor operations that cause multiple edits (notably "slurp" with paredit, at least in Atom). I know this is a "known issue" but wondered whether it was more of an editor issue or a parinfer issue at this point? Is there anything I -- as a user -- can do to help? (great to meet you at Conj, BTW)


I tried turning off paredit to see if I could get along with just parinfer but the smart newline (that auto-indents) and forward slurp are just too valuable to live without them (despite the parinfer peculiarity with the latter). 🙂


I still have Paredit installed in Atom, but I have all the keybindings turned off and separately have "enter" mapped to Paredit's newline in my keymap.cson (which is what I recommend here: I also have a keybinding to select the current sexp, which is nice


@rgdelato Yeah, I have keybindings off and just a handful of specific bindings of my own


@seancorfield This is arguably a bug or feature request with atom-parinfer. Is there an open issue for it?


I don't know if it's fixable off the top of my head. Maybe a special config flag that disables Parinfer when it detects a Paredit hotkey?


@chrisoakman Doesn't look like it. BTW, I also run into this one fairly regularly: (but usually after a duel between parinfer and paredit has messed up the structure/indentation).


Not sure how doing paredit:forward-slurp could signal to parinfer that it should wait for the edit operation to complete before doing anything?


According to @cfleming this is a problem in Cursive too when an edit is performing that would rearrange the code independently of parinfer -- parinfer seems to try to "interfere" while the other edit is still ongoing (multi-step editing).


I think anyone who can just port over the auto-indent newline to parinfer would be a hero


that’s a big pain point that I experience every day


parinfer is going to have problems when multiple changes are not specified in batch


we talked about combining changes as they come in to debounce parinfer processing without breaking


i’d put that far on the roadmap though


Then I guess as long as there's a way to switch parinfer modes so users can switch to paren mode, do their complex editing (paredit), and then switch back to smart mode, we'll be good.


I don’t think it’s due to the changes not being in batch, #176 and #177 are problems where the changes are batched, but still confuse parinfer.


Obviously non-batched changes will be worse, but there are bugs when batching too.


@seancorfield I commented over on your issue there. One thing that can help as a user is a repro case of what you were doing, ideally minimised, but you mentioned that this often breaks undo in Atom which makes that pretty hard.


@cfleming Thanks. Yeah, now that I've actually created an issue for it, I'll try to pay a bit more attention to code where it breaks and actually set up a repro case in the issue (rather than just cursing and fixing my code and moving on!).


Great, thanks - that helps a lot.


I find that usually I can come up with a minimal example, but I understand the algorithm pretty well now.


I have a suspicion that it happens specifically when you try to slurp an expression that has a sub-expression that is also split over multiple lines so I'll try to keep an eye out for that going forward.


I’m totally willing to believe that based on my experience, yeah.


big fan of Parinfer 👏