COE count is off in order-of-operations

[flannery-denny]

These circles are missing from slide 7 of the deck.

@ifslide{
It depends! We can either work

- outside in: @show{(coe '(- 10 ((?ANS +) (?ANS 5) (?ANS 3))))}
- or inside out: @show{(coe '((?ANS -) (?ANS 10) (+ 5 3)))}

@teacher{The Circle of Evaluation for @math{10 - (5 + 3)} is shown on the next slide.}
}

Instead, we circles that we shouldn't see... Fingers crossed that all of the count issues in the deck are being caused by these missing COE.

Noting that these COE didn't used to appear on slides, so this is a new issue, but, once the deck was building, I realized that we needed to pull them out of the @A for slides, because they're an important visual for facilitating the discussion.

[schanzer]

Agreed - this very much looks like a count issue.

@ds26gte I can confirm that the two COEs nested within @ifnotslide and again @ifslide are being counted by the lua script (so the index ticks up four times in total), but the web page for the lesson plan only includes the @ifnotslide DOM. As a result the selector returns a list that is 2 items shorter than the lua count, resulting in everything being off-by-two.

(I'm also wondering if we should use 0-indexing for the filenames, since that's what the browser uses for the results of a selector. My brain hurts after trying to reconcile the markdown indices with the browser indices!)

[schanzer]

@flannery-denny this appears to be fixed. can you confirm?

[flannery-denny]

@schanzer it's better, but the circle on slide 16 should not be 5 * 6

Here's the asciidoc

@do{
  (define exprA '(+ 7 (* 3 2)))
}

@slidebreak

@ifproglang{wescheme}{The code for expressions involving more than one operation will havemore than one pair of parentheses.}
@ifproglang{pyret}{Whether or not there are parentheses in the original expression, the code for an expression with more than one operation requires parentheses to clarify the order in which the operations should be completed.}

[.embedded, cols="^.^3,^.^1,^.^3", grid="none", stripes="none" frame="none"]
|===
|**Expression**               | → | @show{(math exprA)}
|**Circle of Evaluation**   | → | @show{(coe exprA)}
|**Code**                           | → | @show{(code exprA #:parens true) }
|===

@QandA{
@Q{Why does the code for @show{(coe exprA)} end up with two closing parentheses in a row at the end?}
@A{Because there are two circles that need to be closed! }
}

[schanzer]

@ds26gte Flannery is right - the count for circles is still off. The selector I'm using counts all circles (even the ones nested within tables). I think the lua script is not counting circles that appear inside tables.

An ideal solution would be to modify the selector to ignore circles that fall within tables (same trick we used to simplify table indexing, by ignoring nested tables), but table cells have an inconsistent DOM structure that depends on the vertical-alignment setting in the raw asciidoc. I'm afraid the only way to do this is to make sure we count every single circle in the slides.lua pass

[schanzer]

@flannery-denny can you check with the latest commit? It's looking good on my end.

[flannery-denny]

@ds26gte I've checked out to master and I'm seeing something newly strange in the OoO slide build

Slide 16 has 7 + (3 2) (7 + (3 2)) bleeding through

Slide 24 has a bunch of ````` bleeding through.

@ifproglang{wescheme}{
[cols="^1,^2", grid="none", frame="none"]
|===
| @show{(coe `(* 10 -4))}   | @show{(coe `(text "Good work!" 50 "red"))}
|===
}

@ifproglang{pyret}{
[cols="^1,^2", grid="none", frame="none"]
|===
| @show{(coe `(* 10 -4))}           | @show{(coe `(text "Good work!" 50 "red"))}
| Code: @show{(code `(* 10 -4))}    | Code: @show{(code `(text "Good work!" 50 "red"))}
|===
}

lmk if I should close this issue and open a new one.