Open ickc opened 7 years ago
As a user, if all of your filters are panflute, it means we can run them way faster, because behind the hood autofilter avoids loading from stdin and converting to json (and same for dumping). EG:
pandoc -F filter1.py -F filter2.py ...
pandoc -F autofilter ...
This means that once you are running at least one filter, running more is fast even in large documents.
Now, this can't be replicated with pandocfilters because there is no Doc() object. Sure, you could do externall calls, but then it would do exactly the same as the initial pandoc
call, with the only gain being a faster--to--type command (in which case you can just use panzer)
Oh, so there's no way to have a "panflute-style auto-filter" in the case of pandocfilters, even with the main function (or a lookup of the "main function" as mentioned in #7)?
I am not familiar with the pandocfilters design so what I'm going to say might not make sense: e.g. can't we collect all the functions that needed to pass to toJSONfilters and passing all functions as a list?
If there's no way to make the above work, there might still be an advantage of providing a shortcut for all filters. (this won't be as fine-grained as panzer's option.) e.g. filters: [filter1, filter2]
. So pandocpm can still auto-install santinized filters for the end-users in the first run.
The current panflute-filters
key can remains. As far as pandocpm is concerned, anything in panflute-filters
will be auto-installed by pandocpm (when pandoc -F pandocpm
is used), then it will pass these to panflute and let panflute do its magic. i.e. in this case, pandocpm
and panflute
can both be used as a filter. pandocpm
as a filter will recognize both filters
and panflute-filters
and auto-install them. filters
will be run by pandocpm, and panflute-filters
will be passed to panflute. panflute
as a filter only recognize panflute-filters
, and will only run them, but not auto-install them.
Auto-install can potentially has a couple of problem:
I think auto-install should install simple packages only, and print out error message to direct the users to install complex packages.
If so, this will give people more incentive to keep their filter "simple". One problem I'm personally facing is my pantable is growing in complexity. I asked around in https://groups.google.com/forum/m/#!topic/pandoc-discuss/LIAfgkZKUiE about filter arguments. And currently panzer already allow filter arguments. What's your view on this?
And in terms of panflute's autofilters, it seems filter-arg won't work very well. But such feature (auto-filter that offer speed up) seems too good to give up.
@jgm
had considered deprecating pandocfilters to favor panflute (from pandoc-discuss), but when I asked him again he didn't reply. I assume that he will continue to maintain it. (probably because a lot of users are still using it. Porting has incredible friction by just looking at py2 to py3 transitions.)
I wonder it will be worth the effort to convince him to let me maintain pandocfilters, so that necessary changed can be made into it to support some kind of auto-filters better, perhaps even follow panflute's design to make pandocfilters also works as a filter. What do you think?
As we'll see below, "Auto-install, auto-filter, and dependencies" are closely related issues.
Split off from #2:
Relationship between Panzer, Pandocpm, Panflute, Pandocfilters
These are the potential dependencies:
From https://github.com/pandoc-extras/pandocpm/issues/2#issuecomment-262265957
auto-filter and auto-install
auto-filter: should it fall under panflute or pandocpm?
From https://github.com/pandoc-extras/pandocpm/issues/2#issuecomment-272129860:
Additional notes:
This way, pandocfilters will have a more equal ground to panflute in terms of auto-filter and auto-install, which will be easier for adoption.