D 2018-07-03T20:48:31.121
L config
N text/x-markdown
P b05c0dc0124197f4e10501d371cecd5f306a26ecae34aed257e12d40f56e2d6f
U mario
W 3454
## # config:  {…}

The `config:` field is a list of entries describing feature- and
application-level settings.

    # config:
    #    { name: linky, type: bool, description: autolink urls }
    #    { name: xy.title, type: str, value: "blog title" }
    #    { name: perm, type: select, select: 3=USER|2=EX|1=SUP|0=KERN }

[PMD](wiki/Plugin+Meta+Data) is about uniform feature lookup. And
plugin handling goes hand in hand with configuration management.
However it requires a structured field to avoid bulky definitions, yet
support enough variation.

Usually `config:` contains multiple indented lines, each being a
<acronym title="JSON, but quotes optional">JSOL</acronym>-dictionary.

  *  The `name:` associates some variable/constant/expression to a setting.

  *  A few common `type:` names often cover 90% of configuration needs:

       * `bool`/`boolean` would render as checkbox often.

       * `str`/`string` for plain textual content.

       * `int`/`integer` verifies the value to be numeric.

       * `select`/`combo` defining a predefined list of defaults.

  * With `select: "aaa┃bbb┃ccc"` being the alternatives attribute for
    combobox options.

  * `description:` holds some elaboration on the key name.

  * And `value:` just sets a default.


## 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:` even. For instance `name: ALL_UPPERCASE` might become a
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
certianly most versatile.


## select: type

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.


## Other fields and types

Other per-config attributes migh encompass `category:` and `class:` for
decoration or grouping. Or `arg:` and `param:` for defining commandline args
rather than global application settings.

Other types migt be `text` (lengthy textarea-style strings), `color` (color
picker), `file` (filedialog), `table`/`csv`/`dict` for supporting more complex
setting lists.


## 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.

  * Which allows syntax alternatives `[:=>]+` for key-value pairs.

  * Same as shortened/aliased type names add some user-friendliness.

Of course a stringent JSON-parser could be used. But that's obstructing
maintanability, and buys little performance-wise. (Plugin or option
management is rarely done during runtime; but confined to some admin
or installer UI.)


## Purpose

Once config options are easily parseable, it quickly pays off to implement
a centralized option/admin UI. And it sometimes can be combined with plugin
configuration itself. Which is why plugin meta data defines this simple
scheme.


Z 249297a3db84d5409ead722a11e7ef84