#328 macro system not properly event driven

[Joe Allen]

Macros are treated as if they can be called like C subroutines. The problem is that the 'query' function (suspend macro player to allow for user input) allows you to begin a different thread of macro execution (during the query, switch windows and play another macro which also has a 'query'). You should be able to go back to the original window and complete the first macro during the second macro's query, but you can not. Instead you have to complete the macros in reverse stack order (so second macro has to be completed first).

(In emacs on a terminal this is never a problem because there can only be a single prompt line. Emacs with windows has the problem even worse than JOE- now you have multiple frames, each with their prompt line. In emacs, you have answer prompts in stack order between the frames. In JOE this only shows up in macros with query).

Possible fixes:

• Do not allow user to switch windows during macro query.

• Make macro system properly event driven. Instead of calling a macro, code has to push a macro to play on the input, and then return to edloop. Edloop plays the macro a step at a time by pulling the next step from the input. During query, the input stack is saved (this represents the macro thread of execution). When user completes a dialog, continue the macro by restoring the input stack.

The problem with this method is that we need to be able to return to the edit loop any time we want to run a macro. This involves a lot of code refactoring (for example, the calculator can all macros, but you could be deep in the calculators recursive parer when this happens). One solution is co-routines (see the co-routine branch), but that also involves much refactoring.

[John J. Jordan]

Taking into consideration [#346], perhaps coroutine - or really, the Windows branch - is the path forwards.