Repository navigation
Line endings from maxima LaTeX #1777
Description
There's a bug I've found that's highlighted by freetext but not specific to it. If you import one of the new freetext questions e.g. the multiple extractors question and preview it then the ta in the general feedback ascii block is rendered on a single line. If, however, you go into the edit form and save without any changes, everything works fine and the ta is rendered on multiple lines.
It appears, \n line endings are being stripped from LaTeX from maxima here https://github.com/maths/moodle-qtype_stack/blob/f2b637c297f1b6d8bde0cb5852a95d9f931c0287/locallib.php#L125 but the edit form adds \r\n and the \r lives on?
Not sure there's a backwards compatible fix to that. Any ideas what to do about this, @aharjula ?
After import:
After Save:
ta1:castext("If `f({#x1#})={#f1#}` then `{#x1^2*a#}+b={#f1#}`.
If `f'({#x2#})={#f2#}` then
`
f'(x)=2 a x
f'({#x2#})=2 a * ({#x2#}) = {#f2#}
{#2*x2#}a={#f2#}
a={#f2/(2*x2)#}
`
Now using this value for `a` we have
`
{#x1^2*a#}+b={#f1#}
{#x1^2*f2/(2*x2)#}+b={#f1#}
b={#tansb#}
`
Hence `f(x)={#taf#}`.");
General feedback:
[[ascii]]{@ta1@}[[/ascii]]
Activity
aharjula commentedon Jun 22, 2026
Otherwise, a good theory, but the
stack_maxima_latex_tidyis being applied to CASText by theSMLTblock, which gets generated to wrap{@...@}-injections, but only if those injections do not inject inline-CASText (this to avoid duplicate application). In your example, the{@ta1@}is a special injection of CASText which gets identified inct2_latexand should not get the wrapping, well as long as it is not getting any extra processing before that injection and question-variables...I would check what the database shows after import and compare that to what it shows after that save. I suspect there is a difference. If not in the database, then maybe in the Moodle cache system. For fun, try transferring questions between courses using Moodle's "course reuse" logic and see if the same happens then. My long-term theory is that this happens during the input of Moodle-XML question import, but as it has typically not been a big enough issue (as long as people don't use
//-comments in JS) to truly track down. It might even be at Moodle level...Basically, that
stack_maxima_latex_tidyshould only affect things inside{@...@}, nothing outside those and with the very specific exception of not affecting inline-CASText injections.EJMFarrow commentedon Jun 22, 2026
OK, I'm confused then. Updating
to
displays the imported version correctly.
Pretty sure the DB versions are different with
\nafter import and\r\nafter save. Will double check.aharjula commentedon Jun 22, 2026
Interesting, I wonder what goes into CAS and comes back if smlt gets applied at that level. Ohh well, in any case, import is not generating
\r, but the editor does, which is a rather big difference.EJMFarrow commentedon Jun 22, 2026
Have double-checked hex of DB entries and line endings are LF for import and CRLF for save (for question variables at least).
aharjula commentedon Jun 22, 2026
Ohh, the fun. I wonder if this varies depending on what sort of OS one runs. Anyway, odd that CRLF saved stuff would export as something else or would be imported as something else.
aharjula commentedon Jun 22, 2026
In any case, something is off as smlt should not get applied to
ta1, but apparently it is being applied.Just to confirm, what does
/question/type/stack/adminui/compiledquestion.php?qid=<QID>say? Is the question variables bit forta1a list with the form["%root",...]? (I worry there might be acastext_simplifywrapping around it, and that would merge all the strings...) which should not be done for inline-CASText at that point. And I assume thecastext-qtportion has nosmlt-blocks visible.EJMFarrow commentedon Jun 22, 2026
Here's the output from the imported version of the question:
Imported.txt
aharjula commentedon Jun 22, 2026
Thank you. So the reason why it goes to smlt is because it cannot distinguish between "flat" blocks (
{#...#}is a flat block) generating a singular "string" throughsconcatand a normal "string" injection. Hmm... I wonder if I need to make inline-CASText generate some other wrapping to make sure this does not happen or ensure that the compile time simplification of inline-CASText does not do that much simplification.aharjula commentedon Jun 26, 2026
Ok, so the "fix" in the pull request should stop SMLT from being applied to the case in this issue, but we still have that
\nand\r\nissue in play; it just happened to show this other thing.You don't even need to pull that to see if extraneous SMLT was the whole issue; we already had an alternative injection logic. Basically, instead of
{@ta1@}put[[castext evaluated="ta1"/]]inside the[[ascii]]-block.