Don't change the Widget class. Instead implemnt get_value_handler and set_value_handler in the S&R class to special case the handling of this option. You can be as flexible as you want in those methods. A grep in that directory will show you examples of using those methods.
On the GUI:
There are two less than optimal scenarios:
1) The user enters something but does not click add. I which case his expression is ignored
2) The user enters something but does not click clear, in which case the expression is applied even though he did not intend it to be applied.
To me, scenario (1) is preferable, as it makes the feature easier to use for newbies. You can always add a popup that pops up only if there is text in those boxes and asks the user if he wants to apply that text or not. Do these by subclassing commit() in the S&R widget.
On the CLI:
You wont be able to find a serialization scheme that is both robust and easy to enter given the quoting restrictions of most shells. Instead, I suggest using the path to a file for the CLI.If specified, load the expressions from that file. To make it human usable have the file format be something simple like
Code:
single line regex1
replacement expression1
single line regex2
replacement expression2
This also allows for an easy analogue of the save load functionality from the CLI. You will also be able to use this option in the GUI, by writing your table into a temp file and passing it using this option.