Either you run doits in separate process (as Sven demonstrated),
or you run it in UI process, blocking the rest of UI.
Stef, you complaining about not being able to see output of code that blocks a process from doing such output.
I wonder how you going to fix that, and how much other complaints you will face,
once you will fix that.
The solution could be to change the whole UI paradigm and separate rendering from UI handling, which means that display no longer depends on what UI process are busy with. That means a lot of work revising the way how morphic delivers content to the real estate..
Only then Transcript could work as expected, scheduling screen updates into rendering/screen update schedule, as well as many other applications that can benefit from separating rendering pipeline from event handling.
But alas, even then, you won't be fully satisfied, since VM is single threaded and it can be busy only with one thing at a time, either updating your screen, or advancing in progress of an action you instructed it to perform.
And i remember many complaints of the past, where people was really annoyed that 'Transcript is tooooo damn slow' because often for VM it takes more cycles to update transcript than to do any progress with computation you run..
So, the choice is yours: you can run simulation that force updates of its progress every microsecond on screen (so fast, that human eye cannot notice) and as result your simulation takes hours rather than seconds,
or you block the updates , or at least do not update that often (for human eyes updating more than 25 times per second is overkill).