The best way to pass options to filters is through metadata. That gets
considerably easier if the filter can use a function which converts a
structure of metadata objects into a plain data structure so that
`MetsMap`s get converted to plain associative arrays, `MetaList`s to plain
arrays and other `Meta` elements to plain strings or booleans. It is easy
to write such a function using existing walking and steingification
functions.

Once you get the hang of that you don't feel any need to pass custom
arguments to filters because it is so convenient to do filter config in the
document. A useful way to avoid a lot of metadata keys prefixed with filter
names is to have a single key equal to the filter name with a mapping as
value which contains the options for that filter. Nothing hinders you from
also checking environment variables if metadata options are undefined and
use hardcoded defaults only if the env vars are also undefined. I do so
often enough to have written a helper function.

/bpj

fre 6 jan. 2017 kl. 14:00 skrev John MacFarlane <jgm-TVLZxgkOlNX2fBVCVOL8/A@public.gmane.org>:

> +++ Joost Kremers [Jan 06 17 13:27 ]:
>
> >
>
> >On Fri, Jan 06 2017, John MacFarlane wrote:
>
> >>This is a pretty common request.  A couple of complications:
>
> >>
>
> >>1.  Pandoc calls each filter with one argument, the name of
>
> >>the output format.  (Filters thus have access to this.)
>
> >>If we allowed `-F "pantable -t csv"`, how would this work?
>
> >>Would pandoc call `pantable latex -t csv`?  Would the filter
>
> >>be expecting this?
>
> >
>
> >For a properly written filter that shouldn't be a problem, should it?
>
> >You just need to decide on one way of doing it and stick to it.
>
> >Filters then need to be updated accordingly. Or are you worried about
>
> >backward compatibility?
>
>
>
> Well, I'm anticipating people getting confused.  "I said to
>
> run --filter 'myfilter myarg', and for some reason 'myarg'
>
> isn't the first argument!"
>
>
>
> What's wrong with communicating options to filters through
>
> environment variables, which you can already do?
>
>
>
>     PANTABLE_OUTPUT="csv" pandoc --filter pantable
>
>
>
> >pandoc --filter "My Cool Filter.py" --filter-args "-t csv"
>
> >
>
> >with each --filter-args referring to the immediately preceding
>
> >--filters option. Depending on how Pandoc calls filters, it may even
>
> >be possible to just pass it the literal string argument of
>
> >--filter-args without having to parse it into different options.
>
>
>
> I think this is too complex, with --filter-args affecting
>
> the immediately preceding --filter option.
>
>
>
> Again, I'd have to be convinced that environment variables
>
> don't already provide a perfectly adequate way to do this.
>
>
>
> --
>
> 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/20170106125852.GA1662%40Administrateurs-iMac-3.local
> .
>
> 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/CADAJKhCPn81DsWpzWSQHv59ii%2BSLXmz4Ww5ru1mSmP4eRQozow%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.