There is currently no way to wait for a response back from the MUSH before proceeding with an Input /command queue.

[GoogleCodeExporter]

Let's say you have a macro where order of execution is critical.  For instance, 
when you are printing things to the screen that include responses from the MUSH 
server embedded within raw text.

Consider this arbitrary example:
/print [%sometag%
[/send l]
%sometag%]

Will actually print:
%sometag%

%sometag%
[then the output of the 'l' command]

The only way to get around this is hairy right now and not user friendly.
I would have to have a wrapper command that sets the payload of the 'l' command 
to a variable and then recall it back in my print macro.  In some cases, 
immediate processing might be awesome, in others not.  Also, if you consider 
the example and the workaround, this means the player gets spammed twice, once 
with unformatted stuff, and once with properly formatted, but room descriptions 
and other payload strings from the MUSH server might be rather large, spamming 
the player.  In order to remedy that, they'd have to set up an event to pull 
the custom print portion out, but that's currently not easy to do, since as far 
as I can tell, the underlying matcher that the client uses does not support 
multi-line matching.

Original issue reported on code.google.com by fuzzywea...@gmail.com on 9 Mar 2014 at 9:05

[GoogleCodeExporter]

The other way to work around this is simply /send a think command to the MUSH 
server.  My beef with this method (for most areas that accept commands, etc) is 
that this can make the commands/events/etc MUSH dependent, destroying the 
agnosticism of it since it relies on the syntax of a particular MUSH code base.

Original comment by fuzzywea...@gmail.com on 9 Mar 2014 at 9:08