Multiline inputs w/scripts used

I sometimes use the Ctrl-Enter ability to type in several commands to perform while waiting for something to complete. I've noticed that when one of these commands contains a call to a script that performs a world.Send(), it's output always goes first, no matter where it is placed in the list.

Example:

Input:
standardinput1 'Goes directly to the mud
aliasinputwithscript 'Calls an alias with a call to a script that performs a world.Send()
standardinput2 'Goes directly to the mud

Sent to mud:
<aliasinputwithscript output>
standardinput1
standardinput2

More than one alias can match on a particular line you type, so it is possible to make aliases like this:

Alias 1


Alias: (.*)\bd\b(.*)
Send: %1dragon%2
Regular expression: checked


What this does is replace a "d" on its own with "dragon".


Alias 2


Alias: ^k (.*)
Send: kill %1
Regular expression: checked


What this does is change "k <something>" to "kill <something>".

Now, you can combine then, by typing:


k d


MUSHclient sends "kill dragon".

Now, the problem is, when do scripts get executed? One of:

1. Before all alias results are sent
2. As each alias is matched
3. After all alias results are sent

You were hoping for (2), but imagine what would happen in my example. Say, the script for the first alias did this:


world.send "sigh"


Then, what the world would get would be:


kill
sigh
dragon


Or, something like that.

So, as MUSHclient evaluates aliases, it executes the scripts as it finds them, but gradually builds up a "evaluated line". This evaluated line, consisting of the results of alias expansion, speed walking, "omit from log", command stacking, and so on, is then sent to the MUD in one piece.

Alias 1:



Alias 2:


Original user input:
---------------
k d 1
---------------



MushClient matches:
---------------
k d 1            'User input (processable)
---------------
      on
---------------
^k (.*)          'Alias
---------------

Mushclient adds:
---------------
sigh             '.Send input (not to be processed further)
k d 1            'User input (processable)
---------------

MushClient replaces:
---------------
k d 1            'User input (processable)
---------------
     with
---------------
kill d 1         'User input (altered, processable)
---------------




Mushclient continues working and matches:
---------------
kill d 1         'User input (altered, processable)
---------------
      on
---------------
(.*)\bd\b(.*)    'Alias
---------------

MushClient replaces:
---------------
kill d 1         'User input (altered, processable)
---------------
     with
---------------
kill dragon 1    'User input (altered, processable)
---------------



Final output:
---------------
sigh             '.Send input (not to be processed further)
kill dragon 1    'User input (altered, processable)
---------------


You should be able to populate the input commands into an multidimensional array which seperates each item by the newlines in the input string. The first dimenson is the input data, the second dimension contains extended data regarding how/what MushClient should further process/do with the command.

If you were to introduce priorities into aliases, you could also limit them to single hits, so you can force it to stop being processed after any hit.

As you work with each item in the array, if you need to add new data, you can add it before or after(that could be an option supplied for the alias if you enter a script call to execute) any data altered by the alias itself, while maintaining the array structure by following newlines. If there are multiple alias hits for a single line of input, the extended data could be mananged with a null/true/false style variable, and using (And) or (Or) operations on each point of the extended data(determined seperately for each point)

Each item in the array should be fully worked, then begin at the beginning of the array to find the next item to work. Short of a 1000 input with each item needing to be checked, it should be fairly quick to process.

Your comments have been added as suggestion #466.

Fixed in version 3.35 - see the release notes.