Thanks for raising the question, Mike. I occasionally feel a bit frustrated with the lack of a good editor in those fields, too. But I think it would be difficult to turn on Ace without compromising the generality, language-agnosticism and accessibility of CodeRunner. Here's why.
You mention syntax colouring/checking but what language would you configure Ace to use for that? There are four fields in each test case: test code, standard input, expected output and test extra. Standard input and expected output aren't usually code fields, so you couldn't syntax colour them. Test extra is sometimes used for code, sometimes not. So that too couldn't really be syntax coloured. That leaves only the test code field, and even that may not contain test code! For example we have a "Write a program that reads a file" question type in which we use the test code field as the contents of the file. You certainly don't want to syntax colour raw text - that's very confusing.
Even in the normal case in which the test code field does contain code, what language should you configure Ace to use? Most of our questions use a Python template regardless of the language of the student answer. See the
c_via_python question type for example. So the most likely choice of language to use would be that configured into the
Ace language field, unless that is empty in which case you'd want the
Sandbox language. But those fields are in the prototype, not a typical question, so are not currently available to the JavaScript that needs to set up Ace. And even that language choice fails on occasion - we have C questions, scripted with a Python template, in which the Test code is a bash script!
It would of course be possible to add UI components to the question authoring form to configure the Ace languages for the different fields, but I'd be reluctant to head down that path: the question authoring form is already too complicated.
A relatively simple fall back would be to use Ace on all the fields, but without a specific language configured. That would kill the syntax colouring/checking, but would give you improved indenting/outdenting capabilities. But even that has a gotcha or two. Tim Hunt has gone to some trouble to ensure that the UI is accessible to visually-impaired students, an important requirement for UK's Open University. To maintain that accessibility, you'd need to do more that simply turn on the Ace editor - you need extra keystroke handlers to support screen readers.
However, if your institution's CodeRunner use is restricted to only a few relatively simple question types and languages, and you're not too concerned with accessibility issues in the question-authoring form, it would be relatively straightforward to turn on the Ace editor in those fields. You could configure a language for the Test code field (perhaps that used by the question's template) but leave the language unspecified for the other fields. If you wish to explore that option for your own in-house use, I think you would probably want to start by looking at the file amd/src/testareas.js. This configures those text areas in the question authoring form that are not managed by Ace. It used to handle indentation with the tab key, but that behaviour has been compromised by the accessibility-handling code. We probably should revisit that code - it no longer seems to behave as well as it used to. Maybe if indentation and tab handling were improved there, some of your current frustrations would go away, without the need for the full-on capabilities of the Ace editor?