Use ACE editor for test case code in question editor

Re: Use ACE editor for test case code in question editor

de Richard Lobb -
Número de respuestas: 2
I just looked into why the old rudimentary indentation and tab-handling code was no longer working properly in the question authoring form test fields. The setupAllTAs function in testareas.js was expecting to find textareas with a class edit_code, which was what edit_coderunner_form.php was requesting as the attributes of the textareas it created. But setupAllTAs wasn't finding any such textareas, so the initTextArea function was never being called. It seems a change in the Moodle-core forms module around Moodle 3.7 moved the requested class into a wrapper div instead!

I've pushed to github a change to textareas.js that re-implements the old functionality. It doesn't do much: just inserts 4 spaces when you hit tab and autoindents lines to match the previous line. But it might deal with at least some of your frustrations! 
En respuesta a Richard Lobb

Re: Use ACE editor for test case code in question editor

de Mike McDowell -
Thanks for that Richard. Just tried it out on my test server and that will definitely help a bit for sure here.

I was thinking about perhaps a checkbox, similar to the "Template uses ace" under Input UIs in the editor. Maybe the same ability here to allow it for test cases? Can you think of a reason this might be a bad idea?
En respuesta a Mike McDowell

Re: Use ACE editor for test case code in question editor

de Richard Lobb -
It's certainly not a bad idea. But there is the complication of determining what language Ace should be using, though using the same language as the sample answer field would cover most cases.

The problem from my perspective is that even relatively simple changes take a lot more time than you'd expect. If you wanted the checkbox to be persistent (which it really should be - it would be annoying to have to re-click it on each save), you'd need to add a field to the database, which means defining a DB update-protocol. Then there's all the testing - new functionality needs new tests to be added to the test suite. And the functionality needs to be documented.

To be blunt, I can't myself be bothered as I don't really feel a need for that functionality. If you're keen enough to implement all that yourself, and if it doesn't clutter the UI too much, we would certainly consider merging a pull request.