
Input/Output Area
The picture below shows you the main SMM window. The right
part is dedicated for mudding. Text output is written into
the above region and you give your input in the entry widget
below the output area.
Input
By clicking into the output- or input-area the focus is
set to the input. If it has the focus, you will see the
input cursor.
You can now type in your commands.
The input widget will keep a history of your last commands.
The SMM input provides some more functionality, which is
bound to key sequences. Below is the list of the most
useful bindings:
- <Return>
- Sends it input so far to the SMM parser.
If its 'normal' text the parser sends the text to the mud.
For more detailed information about the parser please see below.
- <Up>, <Down>
- Cycles thrue your command history.
Hidden inputs - passwords e.g. - will not be put into the history.
If the last and the previous command are the same, then the last command
wont be put into the command history. And finally empty lines wont
be put into the history either.
- <Tab>
- Will invoke the tabcompletition. Again, please see below for
more detailed information.
- <Ctrl-Tab>
- Will put a <Tab> into your input.
- <Ctrl-a>
- Jumps to the beginning of the line.
- <Ctrl-e>
- Jumps to the end of the line.
- <Ctrl-k>
- Deletes the rest of the line.
- <Ctrl-d>
- Deletes one character.
- <xyz>
- try it out,..
- <xyz>
- Bonus! You can redefine any key sequence to invoke or send any commands!
Have a look at the '#keycom' command in commands section.
The SMM Input Parser
The parser looks for several things and changes the input if
needed:
- A '\' will shield the next character.
That means: the character
following a '\' will loose its special meaning, if it had any. The
'\' will be removed too.
- Text within curly braces ('{}') wont be parsed at all. Further more,
the text within the braces will be a single argument to commands or aliases.
The braces are removed after being parsed.
- Quotes ('""') behave just as same as the curly braces, but
any '$<variable name>' will be substituted; shielding for variables
is not possible within quotes. But sometimes this is exactly what
you want.
- At each unshielded toplevel ';' the text will be splitted and sent to the mud.
e.g.:
'n;e;s'
is just the same as 'n<Return>e<Return>s'
- Unshielded toplevel '$<variable name>'s will be substituted.
- The first character will be checked: if its the SMM-command char
(default is '#', but can be changed). If it is the command char
the command will be invoked.
- The first word will be checked, if its an alias. If yes, the alias
will be substituted.
- If the input is an ordinary input now, it is send to the MUD.
Please keep in mind, that the parser works recursivly and the input is not checked
for endless loops.
For the last lines on the output screen and the so called 'tab-list'
tab-completition
exists. If you type the beginning of a word and press the <Tab>-key
the rest of the word is completed automatically. This esp. useful,
when you are adventuring and are suddenly attacked by "Gorgymphula". Or if
you are talking to someone, who has a ugly to type in name like
"Phaidros": just type in 'P<Tab>'.
If more than one completition is possible you are asked to give in
some more charakters. If you dont give in more characters but type in
more <Tab>'s you begin to cycle thrue all possible completitions.
When a MUD sends its output/text to the client it sends it in one or
more packages without caring about the contents. This can cause some
minor problems, when the client wants to process the recieved text, as
it would process 'sequences' of characters, which could accidentially
be broken up.
This problem is solved for ESC sequences as they are handeled by the
SMM data processing as SMM just waits until the sequence is complete.
Problems may arise, if the user wants to process the text:
e.g. for action triggers. Let me explain it in detail:
Normally you expect the text from the MUD comming line by line .
You miss elite guard.
Elite guard absolutely destroys you with his hit.
...(and so on in a fight)...
Now imagine, that you have an action on 'absolutely destroys you'
which lets you flee, but you recieve the text in two packages splited
right after 'absolutely':
- If I would parse all received packages of text separately,
the action wouldnt be triggered at all.
- On the other hande side one doesnt want to wait, until
the next newline really comes. Sometimes (e.g. password input)
they never come and sometimes you just dont wait so long
(just having a little hangup/lag). E.g. if your
trigger would have been 'Elite guard absolutely'
you would be really angry, if the trigger just dont trigger
because of a missing newline.
Therefor I do two things:
- I do parsing after each received packet of data
- but also parse always the whole last line.
In the above case I would have parsed
- Elite guard absolutely
and then
- Elite guard absolutely destroys you with his hit.
Please keep this behaviour in mind, when you build your
action triggers/substitutions/highlights/notouch lines!
There is more to say about text processing. Read on, please:
action triggers/substitutions/highlights/notouch lines
Please also refer to the corresponding sections in the commands part of this
documentation.
Text parsing exists for the user in four flavors:
- notouch lines:
-
These tell SMM not to do user parsing for this line of text.
- action triggers
-
Invoke automatically actions depending on the received text.
- substitutions
-
These are instructions to change the received text. This is something
real and not just displaying; means: after substitution parsing
continues with the substituted text.
- highlightings
-
Colorizes parts of text.
Now all the parsing must be put into some order, as sometimes it depends
on in which order actions are performed, parsing must be stopped
only of some action triggers, etc...
Therefor 10 levels (0-9) exist for each of the above and parsing is
done in the following way:
for (i=0; i<10; i=i+1) {
if ( notouchline(i) ) break; // ends the for loop at all
actions(i);
substitutions(i);
highlightning(i);
}
So everything of level 0 is parsed first, then level 1 and so forth.
If a notouch line of level 3 is detected, parsing in level 3, 4, 5,..
is not done!
If my explanations are not clear enough please, notify me! Even if this docu
is already years old. I don't expect anybody to be able to program and that
I write perfect docu.

Last modified: Sun Dec 19 20:08:59 CET 1999