Brett on 03 Jun, 2019 10:10 PM
Thanks for the suggestion. It's a good solution to your problem, but I'm not sure it's needed by enough users to justify the extra interface. The easiest solution to long argument fields is to call a shell script instead, then edit the arguments in a text editor where you can see them all. I get that individually toggling arguments on and off would be handy if you're changing parameters frequently, but I just question whether enough users are in that position to make it a feature.
To use a shell script, just create a processor.sh file (with whatever name) and include something like:
Make it executable and point Marked to that instead of Pandoc. You could even pass arguments to that from Marked and reference them as $1, $2, etc. (the actual content is passed via STDIN, thus the cat), so that the ones you change most often could be sent from Marked and all of the defaults would be automatic. It would at least save space in the text field...
Hope that helps!
P.S. I do have hopes and dreams of fleshing out a much better custom processor interface, with multiple processors, each with their own config panels, and even a predicate builder that allows Marked to determine whether or not/which processor to run in different circumstances. Right now that's way down the line on the roadmap, but I'll keep the multi-field arguments idea in mind for that.