Should multiple aliases be processed for one line?

I am in the process of fixing up the way aliases work, with a view to letting them execute commands (eg. other aliases) without having to call a script.

However when I look at the alias handling code it seems that they currently behave in a way that is rather bizarre, and I hope no-one is using this behaviour. :P

In early versions of MUSHclient, multi-alias matches simply replaced individual words. eg.

foo => bar
eat => drink

Now if you typed "foo eat" it would send "bar drink" - both would match and both would substitute.

However in current versions it appears that whilst it still multi-matches, it takes the output from the previous alias, and reprocesses that, in an undefined order, which I personally think is pretty useless.

eg.

foo => bar
bar => sausage

Now if you type "foo" it becomes "bar", then it matches "bar" and it becomes "sausage". However, and this is the important bit, because the evaluation order is undefined it might do this:

You type "foo", it becomes "bar", but because it looked for "bar" *before* "foo" it does *not* become "sausage".

I hope no-one is relying on this behaviour, and would be pleased to get some feedback about how you think aliases should work, if multiple matches are likely on one line.

If no-one expects multi alias matches on one line, then I will simplify the code, and then add the option to "send to" "execute" along the same lines as triggers currently do.

Umm.. Multiple matches on a single line is not what I would have expected.. But then I haven't so far tried anything where such a conflict is possible. My assumption was that like triggers, a 'normal' alias would 'assume' start of line for any match. That is doesn't is a bit of a concern, since imho I would prefer to avoid such things 'unless' I specifically use a regexp to perform such a mid-line substitution. I at least say, 'simplify away'. However, since rexexp still need to work, you may not be able to simplify it completely or you will break that.

I would prefer aliases not be matched on what is sent via the "send" box or via "World.Send", by default.

There are some cases where an alias is identical to a mud command. The purpose of the alias is simply to grab the argument and store it in an alias. For example:

Alias: punch *
Send punch %1
Script: Stores Wild to variable.

If "punch" were grabbed again as an alias, I would go into an infitite loop. Although I could change the alias to something other than the same word it is sending (like "pnch", this is not practical for some plugins where I want to set a variable and want to maintain ease of use).

I would therefor suggest one alias should only call another if it is explicity declared through an option on the alias configuration screen.

Now, in specific relation to what you are talking about:

If a person wants two different strings to match on a command they enter, and have them execute different aliases, then, well, they should have two different regular expression aliases. For example:

Alias: foo
reg.exp = Yes
Send: eat

Alias: bar
reg.exp = Yes
Send: sausage

...would send "eat sausage".

Alias: sust
execute output = Yes (Send to alias matching engine)
Send: foo bar[ENTER]drink water

...would send "eat sausage[ENTER]drink water"

In an ideal world, "foo" would be executed before "bar" because it appears first in the string. You execute aliases according to their order in the 'send string', reading from left to right.

Command Stacking:

Command box: "w;w;pwl;bs guard"

"w": alias? No: Send it.
"w": alias? No: Send it.
"pwl": alias? Yes, exectute (including sending from script).
"bs guard" alias? Yes, execute (including sending from script).

Somehow, MUSHclient is capable of queueing commands. It does it when it's busy executing a script, and receives a command from the interface. (For example, ShadowFyr's script that opened a webpage took some time, and if he typed new commands they would be queued while the script executes). Command stacking should simply break up the commands, in the order they are entered, and use the same queue.

This all seems straight forward to me. ...or have I missed something along the way here?

I didn't mean that an alias would re-match itself, so that the example of "punch *" going into a loop wouldn't happen.

I also didn't mean an alias would match what was sent to the world, rather that this might happen:

alias 1:

match: attack *
send: kick %1

alias 2:

match: kick *
send: cast lightning %1

Thus in this hypothetical case, if the aliases matched in the order 1, 2 (which is not guaranteed at present), typing:

attack kobold

would result in

cast lightning kobold

being sent to the MUD.

However because the match order is not guaranteed I am hoping no-one is actually relying on this present behaviour.

As for your comments on command stacking, the new behaviour would work the way you describe, in fact it basically acts as if each command was typed separately into the command box, and thus they are executed individually and sent in the correct order, excepting three things:

1. The stacked command goes into the command history, not the unstacked equivalent.

2. If the first thing on the line is the scripting prefix, then command stacking is disabled.

3. If auto-say is active, command stacking is disabled.

Uhm, I'm tempted to abandoned this message, cause it's kinda non-sensical, but I'll leave it anyway. Waste of reading perhaps....

I'm sorry, but I don't see what particular problem you are addressing there. As far as I know, there is no existing method to call one alias from another, so I don't see any issue with backwards compatability.

As I stated, if calling one alias from another is to be implemented, then I suggest there should be a specific option per alias to declare on/off, and that the line is executed from left to right.

All other situations should be handlable by using regular expressions, and 'keep evaluating'.

Oh wait, perhaps I just figured out what you mean:

Do you mean that if alias "jkl" is called, and sends (for alias matching) "abc", then it's possible that "abc" would fail to match because "abc" precedes "jkl" on some internal list?

If so, the answer would simply be to re-run the alias matching engine clean, without contining from the point in the list where the initial alias was called. This should be fairly straigh forward:

Command box: sust

Alias: sust
Execute Output: [x] (Yes)
Send: eatfood[ENTER]drink

Alias: eatfood
Execute Output: [x]
Send: open backpack[ENTER]get food from backpack[ENTER]close backpack[ENTER]eat[ENTER]Emote Yum

Alias: eat
Send: eat food

So you send "sust" to alias matching routine. Alias found, execute it.

Since Execute Output is checked, you essentially just throw these lines to the command queue (as if they had been typed in).

Run through the rest of the alias list, but still working on THIS EXPRESSION ["sust"]. List complete, process queued commands:

Send "eatfood" to the alias matching routine. Alias found, execute it. (and so forth).

In the end, it would be like this:

So, all the commands in the queue get executed in the proper order. Each command in the command queue will run through the alias engine as would any command from the command box. ("eat" will match and expand to "eat food" which would send immediately).

I guess there is a minor problem in that logic. If "eat" was an alias that had 'Execute Ouput' checked, then those new commands created by "eat" would appear after the line "Emote Yum" which would be out of order.

Bleh, why oh why did I have to contribute to this thread? LOL.

What about priorities (aka 'seq' in the triggers list) for aliases?

Add ability to 'keep evaluating' aliases and you should cover all bases.

Also will add the ability to temporarily alter aliases by simply adding in a newer one at a higher seq level, etc.

Just an idea.

I think these posts answer one question, no-one is using the alias re-match feature.



Yes, that is what I mean, and why probably no-one is using it.

I am strongly tempted now to implement aliases like triggers, like you can "send to world", "send to notepad", and so on, which they already do partly using rather confusing check boxes.

Also a "keep evaluating" and sequence number would be handy for those cases where you want to, say, pick up a general case and send it to the notepad, but a more specific case and react in another way as well.

As for re-scanning, I plan that if you "send to execute", the send box is reparsed as an entirely new command which means, amongst other things, it would (potentially) re-match all existing aliases. Of course, you then have the possibility of a loop, but I have built in a maximum of 20 re-executions before it bails out.

Magnum, your elaborate example is indeed how I envisage it working, which I think you would agree is a lot more powerful, as you can, when writing alias A, use alias B without having to remember whether it is an alias or not.

Plus, an alias could drop into scripting, which gives you the power to send to the world (or output) as well. eg. the "send" text might be:

/ world.EnableTrigger "mytrigger", 1
world.Note "Trigger enabled"
world.Send "who"
world.DoAfter 5, "laughs"

This version is now available for testing - let me know what you think. :)