Yes of course with `-M` you get all the ugliness (IMO) of a single level of key-value pairs which was my point, but that is no different from traditional command line options, apart from `--option=key=value` where you get an additional level. Sure there are things which you may want to communicate to a filter on the command line and not in the document but those are in my experience in the minority. What do you mean with outputting different formats? If you mean what we usually mean by "output format" in a pandoc context I'd expect the format argument which pandoc gives to filters to suffice in most cases, wouldn't it? It would be a little ironic to start adding command line options to suit different people's filter writing style, since we got filters to avoid adding support for everyone's needed features in the pandoc ececutable. That said if a separate filter option option is implemented it would probably be wiser to implement it analogously to the -M option, something like `--filter-option myfilter:option[=value]` and pass those options to the filter as a second 'line' of JSON, thereby not breaking backwards compatibility. Dual filter/cli scripts can just (a) check whether there are any command line options and (b) whether the first two input records are JSON and do their thing based on that. Den 7 jan 2017 21:51 skrev "Kolen Cheung" : > Is that a realistic scenario? > > At least in my case of pantable it actually is. Because either way it is > calling pandoc to do some heavy lifting. So many of the functions I wrote > will be the same. The only differences are how the options are given, and > then how the input/output format might be different (e.g. from csv as a > filter expects the csv in CodeBlock, but from csv on cli expects just a > plain csv). > > As for hierarchical metadata structures being ugly I don’t think they are. > > They aren’t if in YAML, but they seems to be when specified using -M (or > am I missing something?). In the case of any of the suggested method, the > filter arg is only available to that particular filter, so there’s no > mixing of name spaces. And just to add that sometimes it is not desirable > to put this info in the YAML. e.g. when converting all pandoc Table to > other formats (currently I only have CSV in CodeBlock output, but I might > add some others soon, and not to mention it can works the other way > around), one want to be able to input any random sources (it would very > well be from a .docx) and have the ability to specifies the output format > (say CSV in ClodeBlock, CSS tables using Div, etc.) *without* touching > the documents. > ​ > > -- > You received this message because you are subscribed to the Google Groups > "pandoc-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > To post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > To view this discussion on the web visit https://groups.google.com/d/ > msgid/pandoc-discuss/de2e97b1-17a4-4f70-8c17-b3cd960dceb2% > 40googlegroups.com > > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "pandoc-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/CAFC_yuTR%3D2UQZPN4EFbKTCOAwR9tOoS1%2BsYy5rLRViNo908s-Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.