Currently enforces either "notifo" or "boxcar", but does not yet change
any behaviors in the rest of the module. Also prevents appending or
prepending to the option value.
Issue #226
Follow-up to ref 60632d42f. Initial implementation would lose loaded
options when the module was reloaded, and would cause errors if the
loaded dictionary did not contain all of the option values.
In preparation for renaming the project and supparting multiple
notification services, there needs to be a simple method for migrating
user options to the new module name. Using the built-in dictionary
read/write mechanism, migrating to a new module name would be as simple
as issuing `/msg *notifo save foo` and `/msg *notify load foo`.
When faced with sub-expressions, the parser was not correctly advancing
its iterator to the sub-expression's matching end parenthesis, causing
it to evaluate inner conditions twice, and incorrectly terminate early
when it reached the first end parenthesis.
Added preprocessor flag NOTIFO_DEBUG to generate debug output to
PutModule() to validate the expression parsing logic.
This option allows customization of the boolean logic used to
determine how conditional values are used to filter notifications for
channel messages. It evaluates as a full boolean logic expression,
including the use of sub-expressions. The default value of "all" will
bypass this evaluation and simply require all conditions to be true.
The expression consists of space-separated tokens in the following grammar:
* expression = expression operator expression | "(" expression ")" | value
* operator = "and" | "or"
* value = "true" | "false" | condition
* condition = <any condition option>
Also implemented EVAL command for testing purposes.
For any channel/PM where the user hasn't yet sent a message, the replied
condition would always return false due to failing a `0 < 0`
expression. The fix special-cases last_notification_time values of 0 to
always return true.