8.5. Other trigger features

By default, when a trigger matches, no more checking is done. So if a line would match two or more triggers, only the first would have a successful match and have its action executed. The other ones wouldn't even have a chance to try a match.

If you check the Keep executing triggers after this one matches option, then even if this triggers matches it does not prevent other triggers from being tried. So, if a second trigger matches, the actions of both will be executed. Note, however, that unless this second trigger also has the same option checked, trigger matching will stop at that second trigger.

If you are having trouble with triggers and want to be informed whenver a trigger matches, enable the PreferencesDebug Matches menu. When this is enabled, information about each matched trigger will be printed to stderr. (This means you must start KildClient from a terminal to see the output.)

8.5.1. Rewriter Triggers

Rewriter triggers are a special kind of trigger that allows something not possible with ordinary triggers: changing the received line so that futher triggers work on this changed line.

As mentioned above, the $colorline variable holds the entire line that matched the trigger, including ANSI color codes. Rewriter triggers can alter this variable, and then the other triggers will match on this changed line.

Rewriter triggers run before normal triggers. Also, the Keep executing option (see Section 8.5, “Other trigger features”) is not considered for them: they never stop processing of other triggers, even if that option is not set. The gag options are also not significant for a rewriter trigger; they are always ignored.

Let's see an example of where rewriter triggers can be useful. Suppose you do not want to see an offensive word that might appear in the MUD. A first attempt at filtering could be a trigger like this:

Example 8.8. A profanity filter that does not work
  • Pattern: fuck

  • Action: /$colorline =~ s/fuck/f***/; $world->echo($colorline)

  • Omit (gag) from output: Checked


This works for simple cases, but it is most likely not what you want. Suppose you have a trigger that captures messages sent from a specific channel (such as the one for telepathic communications) and does something, such as changing the presentation of the message or sending them to another window. If someone sends a message over that channel with the f-word, the channel-capture trigger will not work because the line has already been caught the the profanity-filter trigger above. You'll see the message with the bad word filtered, but it will not be captured as a channel message.

You might think about setting the Keep executing option in the profanity-filter trigger, but that would not solve the problem. That trigger would match, and print in the main window the line just with the word filtered. And then the original line would match against the channel-capture trigger, thus acting upon the channel message, but with the bad word intact, because the trigger did not change the line. So you would end up seeing the message twice, but neither case in the way you want.

The solution to this problem is to use a rewriter trigger to filter the bad word before other triggers have a chance to see the line. Our profanity-filter trigger should be like this:

Example 8.9. A profanity filter using a rewriter trigger
  • Pattern: fuck

  • Action: /$colorline =~ s/fuck/f***/

  • Rewriter trigger: Checked


Note that the line is not printed. Rewriter triggers generally need not print anything, because if no other trigger matches the line, it will be printed (with the changed contents). If another trigger matches, let this trigger decide what to do.

Now everything should work: when any line with the f-word is seen, this word is filtered out and the line is changed. If this was a channel message, the channel-capture trigger will see the line with the offensive word filtered and display the message in your special way without the bad word.