> I'm not sure... Is there a way to take cfg_type_bracketed_text and feed it
> into parser again while supplying own cfg_type_t? I mean, is it possible to
> call the parser and tell it to re-interpret cfg_type_bracketed_text as some
> other cfg_type_t?

The bracketed text isn't parsed as such in the first place; the lexer
basically just reads it as a string token, except for counting internal
braces so they're balanced.

Perhaps we could associate the line number value with it, though, and pass
that to the plugin, so that when the plugin parsed its input it would have
an accurate line number to report when errors were encountered.

(If the plugin is parsing its input using libisccfg, then we may need to
update libisccfg so you can set an initial line number. I can't recall
whether such a mechanism already exists.)

> Wondering a bit more about this, there is an alternative:
> Plugin API could contain new symbol (provided by the plugin) which would
> contain cfg_type_t for plugin's top-level config. This symbol could be used
> instead of cfg_type_bracketed_text by the named's parser and resulting cfg_obj
> could be just passed to the plugin (e.g. attached to dctx).
> 
> As a side-effect it would enable users to use "include" in plugin config (I
> guess).
> 
> What do you think? What are viable alternatives?

Seems like overkil, to be honest.