Ok, so I know this is my fault for it coming up -- but it was by accident, honest! (:

Whilst recording a macro (named 'a'), I accidentally included the keystrokes '@a'. So when I had finally pressed 'q' and then tried to play the macro, VS consumed 100% cpu, locked up. Had to kill it and lose what I hadn't saved (not much, since I'm a nervous saver!).

Now, I notice that I can do the same in VIM -- the only difference being that ctrl-c in VIM stops the macro execution. I can't get out of the tight loop in ViEmu. Whilst the recursion was an error on my part, I can see where it might be useful to have some kind of recursion -- for example, doing something a large number of times where the user hasn't figured out exactly how many times to do it, but will rather just watch until it is done. Of course, this requirement would imply a requirement for a break key.

So, there are 3 strategies that I can see to cope with this:
1) Don't allow calling macros from within macros -- not ideal and probably inconvenient for someone
2) Don't allow a macro to call itself -- probably not that inconvenient, but how to you guard against macro a which calls b which calls c which calls a? You'd need to maintain some kind of call stack and traverse upwards at every macro call to check for circular references. Ouch.
3) Simpler, but introduces (perhaps) a slowdown in chained macros: accept a break key (something like a ctrl-C) and check for the break key having been pressed before entering any macro. This would also imply not taking over the event loop from VS -- I'm not sure how close ViEmu is tied into that.