Recent changes to MessageParser_Plugin

MessageParser_Plugin modified by nanotube

nanotube — Fri, 05 Apr 2013 15:35:54 -0000

--- v11
+++ v12
@@ -37,6 +37,8 @@
 If you then send a message "hi, my name is bla", the bot will respond with "hello, bla!".

 If more than one regexp trigger matches, each one will cause its respective response. If one regexp matches multiple times in a message, it will cause multiple responses. 
+
+Tip: If you want to avoid multiple occurrences of the match in the line triggering multiple times, just add a ".*" to your regexp, to consume the rest of the line after the first match. 

 You can use arbitrary supybot commands as the action - be creative, and don't limit yourself to 'echo'. Your imagination is the limit! You'll probably also enjoy the [useful examples](#Useful_examples) section.

MessageParser_Plugin modified by nanotube

nanotube — Fri, 05 Apr 2013 15:35:54 -0000

--- v10
+++ v11
@@ -138,7 +138,7 @@

 Thanks to Joe Julian for this idea. 

-    mp add #supybot-bots "^(s/(.+)/(.*)/([gi]*))$" "echo What $nick meant to say was: [re \"$1\" [histsearch \"$2\" [cif [match i $4] \"echo i\" \"utilities ignore\"]]]"
+    mp add "^(s/(.+)/(.*)/([gi]*))$" "echo What $nick meant to say was: [re \"$1\" [histsearch \"$2\" [cif [match i \"$4 \"] \"echo i\" \"utilities ignore\"]]]"
     alias add histsearch "last --from [echo $nick] --regexp \"/^(?!s\/).*$1.*/@1\" --in [echo $channel]"

@@ -147,7 +147,7 @@
 The setup here is rather complicated, so let's go through it bit by bit. 

   * "^(s/(.+)/(.*)/([gi]*))$" - This matches any message that is of the form "s/pattern/replacement/flags". Replacement may be empty, but pattern may not be. Allowable flags are 'g', for global, and 'i', for case-insensitive. The match groups in this regexp are read from left to right by the opening parenthesis. Thus, group 1 is the whole expression, group 2 is the pattern expression, group 3 is the replacement expression, and group 4 is the flags. 
-  * [cif [match i $4] \"echo i\" \"utilities ignore\"] - This gives the 'i' flag to the _histsearch_ command as an argument, if the 'i' flag was given in the sed regexp. 
+  * [cif [match i \"$4 \"] \"echo i\" \"utilities ignore\"] - This gives the 'i' flag to the _histsearch_ command as an argument, if the 'i' flag was given in the sed regexp. Note the quotes and a space around '$4' - we are making sure we are not passing an empty string to match, even if group 4 is empty. 
   * The _histsearch_ command looks up the last message in the channel from the user, which matches the _pattern_ part of the sed expression, as long as the message itself is not a sed expression (doesn't start with 's/'). Takes optional argument (@1) which is the expression modifier flag (the only useful one is 'i' for case-insensitivity). 
   * The nested _re_ command call uses the whole sed expression as its regexp, then passes the _pattern_ part to histsearch as the first argument, and optionally the 'i' flag, if present. The conditional _cif_ nesting is due to the fact that 'g' is not a valid flag for a matching regexp, which is what the _last_ command is using to find the matching message. Thus we cannot just pass all the flags on to the _last_ command. 
   * Note also the quotes around the arguments passed to _re_ and _histsearch_. These are necessary to be able to pass the regexp literally, and as one argument. Otherwise, spaces in the regexp would break up the argument, and regexp character classes (which are represented with square brackets) would be treated as nested commands, which is not what we want.

MessageParser_Plugin modified by nanotube

nanotube — Fri, 05 Apr 2013 15:35:54 -0000

--- v9
+++ v10
@@ -142,17 +142,17 @@
     alias add histsearch "last --from [echo $nick] --regexp \"/^(?!s\/).*$1.*/@1\" --in [echo $channel]"

-Here we allow a user to enter a sed regexp expression in a message, using the forward slash as the delimiter. The bot then goes and looks up the last message posted by the user that matches the match expression, put the message through substitution by the substitute expression, and output a corrected message. 
+Here we allow a user to enter a sed regexp expression in a message, using the forward slash as the delimiter (a message of this form: "s/pattern/replacement/flags"). The bot then goes and looks up the last message posted by the user that matches the pattern expression, puts the message through substitution by the replacement expression, and output- a corrected message. 

 The setup here is rather complicated, so let's go through it bit by bit. 

-  * "^(s/(.+)/(.*)/([gi]*))$" - This matches any message that is of the form "s/pattern/replacement/flags". Replacement may be empty, but pattern may not be. Allowable flags are 'g', for global, and 'i', for case-insensitive. 
-  * [cif [match i $4] \"echo i\" \"utilities ignore\"] - This gives the 'i' flag to the histsearch as an argument, if the 'i' flag was given in the message. 
+  * "^(s/(.+)/(.*)/([gi]*))$" - This matches any message that is of the form "s/pattern/replacement/flags". Replacement may be empty, but pattern may not be. Allowable flags are 'g', for global, and 'i', for case-insensitive. The match groups in this regexp are read from left to right by the opening parenthesis. Thus, group 1 is the whole expression, group 2 is the pattern expression, group 3 is the replacement expression, and group 4 is the flags. 
+  * [cif [match i $4] \"echo i\" \"utilities ignore\"] - This gives the 'i' flag to the _histsearch_ command as an argument, if the 'i' flag was given in the sed regexp. 
   * The _histsearch_ command looks up the last message in the channel from the user, which matches the _pattern_ part of the sed expression, as long as the message itself is not a sed expression (doesn't start with 's/'). Takes optional argument (@1) which is the expression modifier flag (the only useful one is 'i' for case-insensitivity). 
-  * The nested _re_ command call uses the whole sed expression as its regexp, then passes the _pattern_ part to histsearch as the first argument, and optionally the 'i' flag, if present. The conditional _cif_ nesting is due to the fact that 'g' is not a valid flag for a matching regexp, which is what the _last_ command is using to find the matching message. 
-  * Note also the quotes around the arguments passed to re and histsearch. These are necessary to be able to pass the regexp literally, and as one argument. Otherwise, spaces in the regexp would break up the arguments, and regexp character classes (which are represented with square brackets) would be treated as nested commands, which is not what we want. 
+  * The nested _re_ command call uses the whole sed expression as its regexp, then passes the _pattern_ part to histsearch as the first argument, and optionally the 'i' flag, if present. The conditional _cif_ nesting is due to the fact that 'g' is not a valid flag for a matching regexp, which is what the _last_ command is using to find the matching message. Thus we cannot just pass all the flags on to the _last_ command. 
+  * Note also the quotes around the arguments passed to _re_ and _histsearch_. These are necessary to be able to pass the regexp literally, and as one argument. Otherwise, spaces in the regexp would break up the argument, and regexp character classes (which are represented with square brackets) would be treated as nested commands, which is not what we want. 

-One quirk of this is that backreferences, which usually can be passed directly to _re_ command as '\1', e.g., have to be double-backslashed. Otherwise, in parsing the string, the bot takes these to mean the \x01 character. 
+One quirk of this is that backreferences, which usually can be passed directly to the _re_ command as '\1', for example, have to be double-backslashed. Otherwise, in parsing the string, the bot takes that to mean the literal \x01 character. 

 The result of this can be seen in the following sample session:

MessageParser_Plugin modified by nanotube

nanotube — Fri, 05 Apr 2013 15:35:54 -0000

--- v8
+++ v9
@@ -138,16 +138,32 @@

 Thanks to Joe Julian for this idea. 

-    mp add #sourceforge "^s/(.*)/(.*)/[0-9gI]*$" "echo What $nick meant to say was: [replace \"$1\" \"$2\" [last --from [echo $nick] --regexp /^(?!s\/)/ --in [echo $channel]]]"
+    mp add #supybot-bots "^(s/(.+)/(.*)/([gi]*))$" "echo What $nick meant to say was: [re \"$1\" [histsearch \"$2\" [cif [match i $4] \"echo i\" \"utilities ignore\"]]]"
+    alias add histsearch "last --from [echo $nick] --regexp \"/^(?!s\/).*$1.*/@1\" --in [echo $channel]"

-This one causes the bot to look up the last thing said by the user in the channel, and applies a typo correction to it. The --regexp argument to _last_ makes it ignore messages that start with 's/', because you usually want to correct your actual messages, rather than your typo corrections. For example, see the following session: 
+Here we allow a user to enter a sed regexp expression in a message, using the forward slash as the delimiter. The bot then goes and looks up the last message posted by the user that matches the match expression, put the message through substitution by the substitute expression, and output a corrected message. 
+
+The setup here is rather complicated, so let's go through it bit by bit. 
+
+  * "^(s/(.+)/(.*)/([gi]*))$" - This matches any message that is of the form "s/pattern/replacement/flags". Replacement may be empty, but pattern may not be. Allowable flags are 'g', for global, and 'i', for case-insensitive. 
+  * [cif [match i $4] \"echo i\" \"utilities ignore\"] - This gives the 'i' flag to the histsearch as an argument, if the 'i' flag was given in the message. 
+  * The _histsearch_ command looks up the last message in the channel from the user, which matches the _pattern_ part of the sed expression, as long as the message itself is not a sed expression (doesn't start with 's/'). Takes optional argument (@1) which is the expression modifier flag (the only useful one is 'i' for case-insensitivity). 
+  * The nested _re_ command call uses the whole sed expression as its regexp, then passes the _pattern_ part to histsearch as the first argument, and optionally the 'i' flag, if present. The conditional _cif_ nesting is due to the fact that 'g' is not a valid flag for a matching regexp, which is what the _last_ command is using to find the matching message. 
+  * Note also the quotes around the arguments passed to re and histsearch. These are necessary to be able to pass the regexp literally, and as one argument. Otherwise, spaces in the regexp would break up the arguments, and regexp character classes (which are represented with square brackets) would be treated as nested commands, which is not what we want. 
+
+One quirk of this is that backreferences, which usually can be passed directly to _re_ command as '\1', e.g., have to be double-backslashed. Otherwise, in parsing the string, the bot takes these to mean the \x01 character. 
+
+The result of this can be seen in the following sample session: 

     <nanotube> fill out tihs from
     <nanotube> s/from/form/
     <gribble> What nanotube meant to say was: fill out tihs form
     <nanotube> s/tihs from/this form/
     <gribble> What nanotube meant to say was: fill out this form
+    <nanotube> stuff
+    <nanotube> s/([stuf])/\\1\\1/g
+    <gribble> What nanotube meant to say was: ssttuuffff

 ## More examples

MessageParser_Plugin modified by nanotube

nanotube — Fri, 05 Apr 2013 15:35:53 -0000

--- v7
+++ v8
@@ -138,13 +138,15 @@

 Thanks to Joe Julian for this idea. 

-    mp add "^s/(.*)/(.*)/[0-9gI]*$" "echo What $nick meant to say was: [replace \"$1\" \"$2\" [last --from [echo $nick] --without s/ --in [echo $channel]]]"
+    mp add #sourceforge "^s/(.*)/(.*)/[0-9gI]*$" "echo What $nick meant to say was: [replace \"$1\" \"$2\" [last --from [echo $nick] --regexp /^(?!s\/)/ --in [echo $channel]]]"

-This one causes the bot to look up the last thing said by the user in the channel, and applies a typo correction to it. For example, see the following session: 
+This one causes the bot to look up the last thing said by the user in the channel, and applies a typo correction to it. The --regexp argument to _last_ makes it ignore messages that start with 's/', because you usually want to correct your actual messages, rather than your typo corrections. For example, see the following session: 

-    <nanotube> fill out this from
+    <nanotube> fill out tihs from
     <nanotube> s/from/form/
+    <gribble> What nanotube meant to say was: fill out tihs form
+    <nanotube> s/tihs from/this form/
     <gribble> What nanotube meant to say was: fill out this form

MessageParser_Plugin modified by nanotube

nanotube — Fri, 05 Apr 2013 15:35:53 -0000

--- v6
+++ v7
@@ -111,21 +111,43 @@

 # Useful examples

-Here are a few examples of how this plugin can be extremely useful: 
+Here are a few examples of how this plugin can be extremely useful. 
+
+## Single word in-line commands

     messageparser add ",,(\w+)" "$1"

 This one causes the bot to take one-word commands from in-message, if they're preceded by double-comma. So you could send a message like "Show me your ,,version and your ,,uptime", and you'd get two responses back, one with version, one with uptime. Also very useful for calling up factoids in-message. E.g. "see the ,,rsync docs" will output the rsync factoid, if the plugin is loaded and the rsync factoid exists. 
+
+## Multi-word in-line commands

     messageparser add ",,\(([^\)]*?)\)" "$1"

 This one causes the bot to take multi-word commands from in-message, if they're preceded by double-comma and open-parenthesis, and closed with close-parenthesis. So you could send a message like "I'd like a ,,(factoids search *) please", and you'd the output of command 'factoids search *'. 
+
+## Output-redirect style addressing

     messageparser add "^\)(.+)\s+\|\s+([\w\-\[\]\`^{}\|]+)" "echo $2: [$1]"

-This implements the "output redirect" style functionality, so you can have the bot address a nick of your choice with the output of a command. So, e.g., a message like ")version | JoeSmith" will cause the bot to respond with "JoeSmith: <version output here>". Note here that you don't want the starting character to be your bot's regular trigger character, otherwise in addition to the messageparser output, you'll get errors on invalid command parameters for the pipe and user nick following it. Note also that the complexity of the second match group is due to it including all characters allowed in IRC nicks. 
+This implements the "output redirect" style functionality, so you can have the bot address a nick of your choice with the output of a command. So, e.g., a message like ")version | JoeSmith" will cause the bot to respond with "JoeSmith: <version output here>". Note here that you don't want the starting character to be your bot's regular trigger character, since messageparser ignores commands directly addressed to the bot to avoid unintentional 'double-output'. Note also that the complexity of the second match group is due to it including all characters allowed in IRC nicks. 
+
+## Ex-post typo correction
+
+Thanks to Joe Julian for this idea. 
+    
+    mp add "^s/(.*)/(.*)/[0-9gI]*$" "echo What $nick meant to say was: [replace \"$1\" \"$2\" [last --from [echo $nick] --without s/ --in [echo $channel]]]"
+    
+
+This one causes the bot to look up the last thing said by the user in the channel, and applies a typo correction to it. For example, see the following session: 
+    
+    <nanotube> fill out this from
+    <nanotube> s/from/form/
+    <gribble> What nanotube meant to say was: fill out this form
+    
+
+## More examples

 If you come up with other useful examples, please do let me know and I'll include them here.

MessageParser_Plugin modified by nanotube

nanotube — Fri, 05 Apr 2013 15:35:53 -0000

--- v5
+++ v6
@@ -38,19 +38,7 @@

 If more than one regexp trigger matches, each one will cause its respective response. If one regexp matches multiple times in a message, it will cause multiple responses. 

-You can use arbitrary supybot commands as the action - be creative, and don't limit yourself to 'echo'. A couple of my favorites are: 
-    
-    messageparser add ",,(\w+)" "$1"
-    
-
-This one causes the bot to take one-word commands from in-message, if they're preceded by double-comma. So you could send a message like "Show me your ,,version and your ,,uptime", and you'd get two responses back, one with version, one with uptime. 
-    
-    messageparser add ",,\(([^\)]*?)\)" "$1"
-    
-
-This one causes the bot to take multi-word commands from in-message, if they're preceded by double-comma and open-parenthesis, and closed with close-parenthesis. So you could send a message like "I'd like a ,,(factoids search *) please", and you'd the output of command 'factoids search *'. 
-
-Your imagination is the limit! 
+You can use arbitrary supybot commands as the action - be creative, and don't limit yourself to 'echo'. Your imagination is the limit! You'll probably also enjoy the [useful examples](#Useful_examples) section. 

 ### regexp uniqueness

@@ -120,3 +108,24 @@

 for help on each one. 
+
+# Useful examples
+
+Here are a few examples of how this plugin can be extremely useful: 
+    
+    messageparser add ",,(\w+)" "$1"
+    
+
+This one causes the bot to take one-word commands from in-message, if they're preceded by double-comma. So you could send a message like "Show me your ,,version and your ,,uptime", and you'd get two responses back, one with version, one with uptime. Also very useful for calling up factoids in-message. E.g. "see the ,,rsync docs" will output the rsync factoid, if the plugin is loaded and the rsync factoid exists. 
+    
+    messageparser add ",,\(([^\)]*?)\)" "$1"
+    
+
+This one causes the bot to take multi-word commands from in-message, if they're preceded by double-comma and open-parenthesis, and closed with close-parenthesis. So you could send a message like "I'd like a ,,(factoids search *) please", and you'd the output of command 'factoids search *'. 
+    
+    messageparser add "^\)(.+)\s+\|\s+([\w\-\[\]\`^{}\|]+)" "echo $2: [$1]"
+    
+
+This implements the "output redirect" style functionality, so you can have the bot address a nick of your choice with the output of a command. So, e.g., a message like ")version | JoeSmith" will cause the bot to respond with "JoeSmith: <version output here>". Note here that you don't want the starting character to be your bot's regular trigger character, otherwise in addition to the messageparser output, you'll get errors on invalid command parameters for the pipe and user nick following it. Note also that the complexity of the second match group is due to it including all characters allowed in IRC nicks. 
+
+If you come up with other useful examples, please do let me know and I'll include them here.

MessageParser_Plugin modified by nanotube

nanotube — Fri, 05 Apr 2013 15:35:53 -0000

--- v4
+++ v5
@@ -1,4 +1,6 @@
 The MessageParser plugin allows you to set custom regexp triggers, which will trigger the bot to respond if they match anywhere in the message. This is useful for those cases when you want a bot response even when the bot was not explicitly addressed by name or prefix character. Read on to see how to use it, and just how useful it can be. 
+
+The code for this plugin lives in the [git repository](http://gribble.git.sourceforge.net/) of the [gribble sourceforge project](http://sourceforge.net/projects/gribble).

 [TOC]

MessageParser_Plugin modified by nanotube

nanotube — Fri, 05 Apr 2013 15:35:53 -0000

--- v3
+++ v4
@@ -105,7 +105,7 @@

 This commands [vacuums](http://www.sqlite.org/lang_vacuum.html) the sqlite3 database of regexps. By default it requires the 'admin' capability to run. This can be changed through the _requireVacuumCapability_ config. 

-## Configuration
+# Configuration

 Supybot configuration is self-documenting. Run

MessageParser_Plugin modified by nanotube

nanotube — Fri, 05 Apr 2013 15:35:53 -0000

--- v2
+++ v3
@@ -103,7 +103,7 @@

 ## MessageParser.vacuum

-This commands [vacuums](http://www.sqlite.org/lang_vacuum.html) the sqlite3 database of regexps. By default it requires the 'admin' capability to run (settable in the plugin's config). 
+This commands [vacuums](http://www.sqlite.org/lang_vacuum.html) the sqlite3 database of regexps. By default it requires the 'admin' capability to run. This can be changed through the _requireVacuumCapability_ config. 

 ## Configuration