Hi Erik,
What you have here looks great. The only question I have is that you seem to be treating modes which hold a value and modes which are on / not on the same. This is fine but I don't think that generalized booleans should be the right way to look at it: rather modes whose value are t / nil are modes which are on / not on, and modes which have some non-boolean value are modes which hold a value. Does this make sense? Is it the way you've implemented it in the code?
Hi Brian,
The code differentiates two different mode types: single and multi value. The single value mode can be used for two different purposes: modes with on/off values and modes with a non-boolean value. (This could easily be changed ofcourse, but read on...)
The behaviour of the single value mode is based on the premise that boolean value modes don't take an argument when being set, whereas non-booleans do take a value. When the set-mode-value method is called for a single-value-mode with a nil value, the mode acts as a boolean and sets the value to t.
As I'm writing this, I think I should add a boolean-value-mode class which does exactly that and makes the library a bit more transparent. set-mode-value for a single-value-mode with a value argument of nil would (as expected) set the value to nil (that being equal to unset-mode-value).
The boolean-value-mode can be implemented in maybe 10 lines. Then one more line change is required to actually use the mode. 1 or 2 lines can be removed from the single-value-mode which special-case the nil value argument to the set-mode-value method. All in all not something big.
Thanks for your comments.
bye,
Erik.