under the list …
Contents
Separators
Formatting
Transformations
Replacements
Footnotes/Comments
it would be helpful to add a reference to “Post-Compile scripts” (bash or python)
Post-Compile Scripts …
e.g. for MultiMarkDown the mmd document containing mmd syntax
could be compiled as *.txt format and on clicking Compile
this Post-Compile script is launched
then the compiled document text stream is piped
to a selected bash or python script from a scripts folder
$ cat /path/to/mmd_document.txt | multimarkdown
…
other scripts might analyse the compiled document such as concordance
so the wish is for general scripting to be added Post-Compile.
…
This wish might go against the Scrivener development policy not to add 3rd party plugins (including scripts).
Thanks, I noticed you’ve been working on trying to get MMD working with Linux. One of the ingredients of the MMD system is an open-ended scripting back end. I’m not sure what the state of that alternative is on Windows at the moment, but it would certainly be easier in the Linux environment, which like the Mac, often comes out of the box ready to run Perl and XSLT processing. At any rate, the trick is to use MMD’s Mac support package to get the Perl scripts, they should work fine on Linux (with a little environment checking perhaps). In theory, if they are installed in the correct location they will be executed instead of the internal scripts or MMD binary. So naturally, once you get to that point, you can see how the stage is wide open. All Scrivener is doing is dumping the compile output as STDIN into a script file and waiting for STDOUT so it can pipe it into the file the user types into the compile window. You can do something entirely different with it if you want—needn’t even use MMD.
However it sounds like the entire execution chain is a bit broken on Linux right now. Neither the distributed binary nor the edict to use an installed binary is functioning properly, and since adding user-land scripting alternatives to either of those is of lower priority for the Windows project (since Windows has little concept of this kind of stuff), I bet that it’s not implemented yet. I’ll have to check.
But yeah, given that all of this is just really making things convenient and easy to use, they are lower priority. Those willing to script their own automation are certainly more likely to know how to use a command line. The integration kit is really meant to make GUI users more at home with a system that otherwise requires a touch of UNIX familiarity. Those that know how to script shouldn’t have any problems compiling a plain MMD text file and running it through whatever automation they devise on the shell.
I’m not sure where you picked up on that. We have no such policy, and in fact have plans for extensive user-land scripting systems, and maybe a plug-in API down the road if the software becomes popular enough for companies like Endnote to consider writing a plug-in. Right now it would be somewhat wasteful to pursue that avenue. User-land interface scripting though, would be coming first.
Until there is some clarification on this (in Linux version) I’ll have to make do with compiling just .txt files from Scrivener then using external bash or python scripts to pickup the output files with mmd syntax to pass to MultiMarkdown.
…
re: my incorrect impression that 3rd party plugins are not supported
I think I may have got that idea from reading this …
Well like I said before, I don’t think there is an alternate pick-up location, since Windows is the primary build target right now and all of this is all quite a bit less useful on Windows without install a bunch of stuff, so very low priority. There are other bugs with MMD that need work first—like section titles not even functioning correctly.
On the Mac the locations are [~]/Library/Application Support/MultiMarkdown, so a more analogous location would be /usr/local/share/multimarkdown or perhaps ~/.multimarkdown as well for non-admin users. Does that sound logical to you? If so I’ll put it into the ticket for resolving this.