@bnmnetp I'm getting some strange behavior out of self.state.nested_parse() when the directive has content that isn't composed solely out of other directives (i.e. text). The content is getting parsed twice--for example, in the RST
.. clickablearea:: click1 :question: Click on all assignment statements. :feedback: Remember, the operator '=' is used for assignment. :click-incorrect:def main()::endclick: :click-correct:x = 4:endclick: for i in range(5): :click-correct:y = i:endclick: :click-incorrect:if y > 2::endclick: print(y)
, the code block starting with :click-incorrect: is getting rendered once normally, then once again after the full component has been rendered like this:
<dl class="docutils"> <dt>:click-incorrect:def main()::endclick:</dt> <dd><p class="first">:click-correct:x = 4:endclick: for i in range(5):</p> <blockquote class="last"> <div><p>:click-correct:y = i:endclick: :click-incorrect:if y > 2::endclick:</p> <blockquote> <div>print(y)</div></blockquote> </div></blockquote> </dd> </dl>
Do you know why this is happening? It's a big roadblock and I'm unsure of what to do about it.
$(...).method() is not a functionwhere
methodis any number of different methods. I'll try a couple other methods and see if anything works.
<pre data-component="parsons" id="question1_100_4"> <span data-question>sc-1-3: Construct a block of code that correctly implements the accumulator pattern.</span>x = 0 for i in range(10) x = x + 1</pre>
if (x in [‘java’, ‘cpp’…])in the first place.
I'm struggling a bit with figuring out why the multi-line isn't working. The Sphinx side is actually working pretty well--most of the code that I deleted from the old parsons.py is functionality that needed to be implemented in the JS, because it was turning multiple line code into single line code with a "\n" replacing the actual newline character, which I should be able to do easily in the JS side. However, even when I hardcode some code in the JS side from an actual working example from the site--for example:
import turtle\nwindow = turtle.Screen()\nella = turtle.Turtle()
This should render one draggable parsons element that is multiple lines of code, but when I hardcode it and pass it into the ParsonsWidget object, it actually still renders as one draggable element, but it is one really long line with actual spaces instead of newlines. Also, I realized that in working examples of Parsons on interactivepython.org, all of the draggable code on the parsons problems have their text wrapped in a multitude of <span> elements. It looks like this happens in prettify.js, and we're including it in our test pages, but none of our code is being wrapped in those spans. I'm wondering if these two things are related.
@flysaiah there is still a little problem with the parsing of the parsons problems on the sphinx side. Can you find a few minutes to look at this example:
.. parsonsprob:: question1_100_4 Construct a block of code that correctly implements the accumulator pattern. ----- x = 0 for i in range(10): ===== x = x + 1 y = 10 ===== print x
You will see that the y=10 line gets indented several extra spaces in the generated code.
def parse_multiline_parsons(self, lines): current_block =  results =  for line in lines: if(line == '====='): results.append(self.convert_leading_whitespace_for_block(current_block)) current_block =  else: current_block.append(line) results.append(self.convert_leading_whitespace_for_block(current_block)) return "\n".join(results) def convert_leading_whitespace_for_block(self, block): whitespaceMatcher = re.compile("^\s*") initialWhitespace = whitespaceMatcher.match(block).end() result = block for line in block[1:]: result += '\\n' # not a line break...the literal characters \n result += line[initialWhitespace:] return result