People have built event-driven app toolkits without closures or continuations. So something like that could be built as-is.
(Continuations give me the headache, or they did the last time I tried to use them, which was… 1989?)
The current Main() can be viewed as an event loop anyhow – the wait-for-event call is buried a few levels down, but it’s the first interesting call in the loop (PARSE_COMMAND_R calls Parser__parse) and that’s immediately followed by event dispatch (GENERATE_ACTION_R). The rough spot in the analogy is that Parser__parse has to convert the “raw” event (a line of text) into a “processed” event (an Inform action) for dispatch, which takes buckets and buckets of code. But notionally, it’s just returning an event to dispatch.
(My plan will keep that model. I’m extending Parser__parse, giving it the ability to convert new input types – hyperlinks, etc – into Inform actions. This will of course bypass all the text-parsing machinery. It’ll just be a rulebook where the game can say “Hey, hyperlink N, that means action Q.”)
Do you need to delve into the Parser code so much then? If you set the global variables you could just immediately jump to the generate action rule.
Maybe what could be done is to remove the input stuff from Parser so that it starts with a filled buffer and generates an action, and other input modes call a different function rather than the parser. Maybe that’s what you’re already planning!
Also: There are cases where you want to skip or repeat the Input stage. Currently those work by a simple (albeit ugly) set of gotos inside Parser__parse. I’d just as soon not futz with that at the same time as I’m making all these other changes.