til_settings: don't check values on nested settings

There needs to be more flexibility in the value checking
enforcement.

This is just a quick blunt-hammer fix to not trip over nested
settings values which will be huge undeterministic messes vs.
what's likely just a set of simple presets in the spec.values[]

The individual leaf settings will still be checked if they
specify values.  So this change just stops even bothering to
check unless the setting is a leaf.

This area needs more work in general, see comments.

For instance right now we can't just pass in arbitrary floats for
settings which list float values, not if that arbitrary float
isn't a member of the list.  In some circumstances that's the
right thing to do, as in the module can only work with the
presets.

But most of the time, the module would be perfectly happy with e.g.
foo=.3379 with foo's spec.values[] = { .01, .1, .25, .75, 1} so
the check fails.  That's dumb, and interferes with the creative
process when you're just poking different numbers into the
settings to see what happens.

TODO

1 files changed, 11 insertions, 1 deletions

diff --git a/src/til_settings.c b/src/til_settings.c
index 71aefb4..4749372 100644
--- a/src/til_settings.c
+++ b/src/til_settings.c
@@ -431,18 +431,28 @@ til_setting_desc_t * til_setting_desc_free(const til_setting_desc_t *desc)
 }
 
 
+/* TODO: spec checking in general needs refinement and to be less intolerant of
+ * creative experimentation.
+ */
 int til_setting_spec_check(const til_setting_spec_t *spec, const char *value)
 {
 	assert(spec);
 	assert(value);
 
-	if (spec->values) {
+	/* XXX: this check can't really be performed on anything but "leaf" settings. */
+	if (spec->values && !spec->as_nested_settings) {
 
 		for (int i = 0; spec->values[i]; i++) {
 			if (!strcasecmp(spec->values[i], value))
 				return 0;
 		}
 
+		/* TODO: there probably needs to be a way to make this less fatal
+		 * in the spec and/or at runtime via a flag.  The values[] are more like presets,
+		 * and especially for numeric settings we should be able to explicitly specify a
+		 * perfectly usable number that isn't within the presets, if the module can live
+		 * with it (think arbitrary floats)...
+		 */
 		return -EINVAL;
 	}