I’m enjoying the flexibility provided by multimarkdown, including the ability to add one’s own programming by hacking into one of the MMD programs–/usr/local/bin/markdown or ~/Library/Application Support/MultiMarkdown/bin/mmd2tex-xslt or mmd-xslt. (There is a bug with these: calling an MMD compile option with XSLT processing on returns
Mktemp’s trouble is that the working directory it inherits from Scrivener is “/”. It would be better if it was the directory of the output file, since the user is more likely to have write permission there. Adding a “-t” option to mktemp is the quick workaround, but that’s technically not part of Scrivener.)
Would it be possible to have a directory, whether MMD’s bin directory or one under ~/Library/Application Support/Scrivener, whereby any program within it comes up as a compile option. Scrivener would treat it just like it does the XSLT MMD programs (sending the processed MMD text to standard input, capturing standard output into the file chosen by the user), but it would mean not having to hack existing programs.
This seems to me a simple change, and has zero implications for people who don’t make use of the feature.
Might it be better to have a setting somewhere for setting a custom post-processor, like Marked handles it? This is something I’ve had on the list of things to consider for a bit now, and that strikes me as more straightforward than a magic directory feature, and would enable the user to also supply what will most likely be all important command flags for proper output handling. Granted a person could create a shell script with all of that in the magic directory, but that takes things to the next level of geekiness that a custom command line would not, as someone only passingly familiar with UNIX could Google a command and paste it in there.
Yes, I take your point about less geeky users, and if your suggestion was fully featured, it would have much better flexibility than a magic directory. My full list of features would be as follows: there could be more than one such option; each option would become its own item in the output menu; each option could specify the kind of input it receives from Scrivener (text, MMD &c, though personally I’m only interested in MMD); each option could (optionally) specify the type of output, restricting the file name suffix like it does presently, and also creating a directory if there are images to be included; lastly, there would be an option to pass the chosen file name/directory to the program as an argument (e.g. by placing % in the command line). Actually, the last one is perhaps the most important, especially for PDF creation from latex–I currently have to specify my destination as an MMD tag.
Time flies! I didn’t realise I opened this thread nearly four years ago. Having the ability to add a post-processor in place of/in addition to multimarkdown seems like a simple change that would simplify automating post-processing.
In the years since, this idea has been thought over and turned down. Sorry about that, I’d like to have more integration with all of OS X rather than just the graphical half of it, but it doesn’t look like we’ll get anything like that any time soon. There will still be the external script calls that we can use to get around that though.
Adding a “-t” option to mktemp is the quick workaround, but that’s technically not part of Scrivener.)