parse() reads escaped %% and {{ }} as fields, and {-style format specs as part of the field name

parse() treats escaped literals as fields for the % and { styles, and reads a { style conversion/format spec as part of the field name.

#69 fixed this for $ ($$ is now skipped). The other two styles have the same class of problem.

The quickstart says the standard-library styles exist so you can use these formatters "with your existing config", so a format that works with logging.Formatter should select the same fields here.

Oracle used: the substitution engine itself — fmt % tracking_dict for %, string.Formatter().parse() for {, string.Template(fmt).get_identifiers() for $. Over 37 formats: $ 7/7 agree, % and { diverge 13 times.

The { cases look the most likely to bite: "{levelname:>8} {message}" is an ordinary stdlib format (StrFormatStyle.validate() accepts it), and with a JSON formatter it emits a "levelname:>8": null key while dropping levelname entirely.

Happy to put up a PR — the shape I have working is % skipping %% the same way $ skips $$, and { using string.Formatter, which is what logging.StrFormatStyle.validate already parses the same string with (it also handles nested specs like {levelname:>{width}}, which a regex does not).

Investigated with AI assistance; the differential above was run locally and I have reviewed and tested the result.

Start by locating parse() and its existing tests, then compare its % and { style handling with the substitution behavior described in the issue and the standard-library parsers named there. Add coverage for escaped literals, conversion and format specifications, including nested specs; done means parse() selects exactly the fields that are actually substituted without changing the already-correct $ behavior.