A couple things to keep in mind with Lua and programing within UIM:
"Lua" is a proper name, it is not an abbreviation. So LUA is incorrect capitalization - Grin...
Always test your return variables - UIM is like a toddler, it will usually do what you expect but every so often it will do something that's completely unexpected.
So
s = alarm.get()
should be followed by
if ( s ~= nil ) then
-- your code here
else
-- your error handling here
end
Lua has two sets of scoping in a script - the outermost level (where you define s and t) is a global list that's searched sequentially. That means it will be slow. Anything scoped inside that is in a hash table that's on the stack and so much faster to use. You can dramatically (sometimes) increase the speed of your code by enclosing all the code within a do/end. That takes your variables out of the global scope and puts them in the local scope.
Always define your variables -
local s = alarm.get()
is more proper.
Tables are just tables. It is important not to draw too many assumptions about them. Your initialization is correct because in the absence of an id, Lua uses a sequential integer that starts a 1 and increases predictably. It is cleaner and more obvious though to force the assignment so instead of
local cleaner = {
{ "&", "&" }, -- decode ampersands
{ "—", "-" }, -- em dash
{ "’", "'" }, -- right single quote
I'd suggest using
local cleaner = {
{ [1] = "&", "&" }, -- decode ampersands
{ [2] = "—", "-" }, -- em dash
{ [3] = "’", "'" }, -- right single quote
The '#' table size operator is somewhat implementation independant. It will probably be right in the simple usage here but as soon as you start adding and removing items from a table, all bets are off. It is better to iterate over a table with pairs()/ipairs() or to use the looping construct with a terminator like while (cleaner[i] ~= nil)
You current code calls string.gsub 14 times. it would be faster to have at the beginning (note replacing the '.' with '_'):
do
local string_gsub = string.gsub
then in the for loop, use the local variable:
t = string_gsub( t, cleans[1], cleans[2] )
The string object will be in that global list of objects and hence slower to access than a local variable. It's not of value if you need the function only once but at some point (you'd have to test to find the actual number) it's faster to take the extra step to create and assign the local variable. My experience is that 14 calls is enough to make a difference.
And finally, as an overall comment, I appreciate the design of creating a table to drive the following code because it lends itself to easy understanding and maintenance but AO scripts aren't homework assignments in a CS class, they are smack dab in the middle of the limiting factor in processing alarm flow. Every CPU cycle can be important. So, consider ditching the table and looping structure and just having the 14 gsub calls in order. Messier but you eliminate all the table creation and accessing, the I variable, the cleans variable, and the looping structure.
Oh, and make sure you understand the impact of on arrival/on overdue/etc settings on the profile itself.
Just my 7 cents on the script
-Garin