Changes to "config" between 2018-07-04 14:21:05 and 2018-07-04 14:22:11

59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83

84
85
86
87
88
89
90
59
60
61
62
63
64
65

66





67










68
69
70
71
72
73
74
75







-

-
-
-
-
-

-
-
-
-
-
-
-
-
-
-
+







    <th><code>value:</code></th>
   <td>just sets a default</td>
</tr>
</table>

#### }

## Storage and key `name:`

Notably this scheme just defines a list of available options. It does **not**
prescribe if they're stored in an `.ini`, `.json`, `xml` or code file, or a database
perhaps.  
Applications might utilize different stores even, and dispatch depending on
the `name:` syntax

  * For example `name: ALL_UPPERCASE` might become a code constant,
  * While `name: sectioned.feature.option` indicated an INI setting,
  * Or `name: "$cfg.plugins[after][]"` even a literal code target.

So names can be somewhat free-form. I'd avoid including the `$` sigil
however, or spaces obviously. Mostly-alphunumeric and dotted keys are
certainly most versatile.


## `select:` type and alternatives
## `select:` alternatives

The syntax for `select:` is

 * preferrably `"alt|alt|alt"`
 * or with optional title `"1=title|2=alternative|3=…"`.
 * Though implementations may allow to use `,` comma and `|` dash.
 * Or `:` like `=` again.
100
101
102
103
104
105
106

















107
108
109
110
111
112
113
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115







+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+







Other types might be

 * `text` for lengthy textarea-style strings),
 * `color` for a color picker,
 * `file` bringing up a file selection dialog
 * Or `table`/`csv`/`dict` for supporting more complex (Excel-style) setting lists.


## Storage and key `name:`

Notably this scheme just defines a list of available options. It does **not**
prescribe if they're stored in an `.ini`, `.json`, `xml` or code file, or a database
perhaps.  
Applications might utilize different stores even, and dispatch depending on
the `name:` syntax

  * For example `name: ALL_UPPERCASE` might become a code constant,
  * While `name: sectioned.feature.option` indicated an INI setting,
  * Or `name: "$cfg.plugins[after][]"` even a literal code target.

So names can be somewhat free-form. I'd avoid including the `$` sigil
however, or spaces obviously. Mostly-alphunumeric and dotted keys are
certainly most versatile.


## Regex tokenizer

You can get by with a somewhat simple regex extractor for this config
scheme. It's simply finding `{…}` pairs, then splitting key-value pairs,
and handling optional quoting.