Multimarkdown 5 released...

Just a FYI for those who use MMD:

fletcher.github.io/MultiMarkdown … notes.html
github.com/fletcher/MultiMarkdown-5

Not a major change, though a bug (whitespace after footnotes in ODT files) that frustrated me enough to build a ruby script to edit .FODT files to patch, has now been fixed. 8)

Homebrew has already been updates so a brew update will get you the newest MMD. Would be nice to get the updated MMD into Scrivener (I know, support package allows you to use an installed version, but we really shouldn’t need to install this to get Scriv to use the system mmd).

Thanks! I’m not sure how ready it is for prime time yet, since Fletcher doesn’t seem to be linking to it from the MMD homepage—but I’m going to go ahead and start testing with it, keeping a copy of 4.7.1 around just in case.

By the way, you needn’t install the support package to use a system copy of MMD installed to the usual /usr/local/bin location. The only reason to use the support package is if you wish to make use of XSLT customisation. You might be thinking of a few years back when MMD went from Perl scripts to C code, when for a period of time Scrivener hadn’t been updated for it yet. For Scrivener and a few other programs that had hard-coded checks for ~/Library/Application Support/MultiMarkdown, the support package became in part an XSLT infrastructure and a set of simple wrappers redirecting software’s requests to the new executables. That hasn’t been necessary since we revamped Scrivener’s compiler for MMD 3.

Or at least it shouldn’t be. Let me know if you are observing otherwise. The specs call for a check on /usr/local/bin/multimarkdown, failing that it will drop to using its internal executables. When using XSLT post-processing, the software should check ~/Library first, then /Library and fall back to an internal support folder copy otherwise.

AmberV: Sorry to reply so late. I didn’t know Scriv does try to check /usr/local/bin/ first — thanks for that info! Do you know how I can know which binary Scrivener uses, is there a compile log or something, it is hard to know if Scriv uses a system mmd otherwise?

Another point for those trying MMD V5.0 using homebrew — the alias scripts (mmd2odf etc.) are not installed any more so you need to update to use the proper flags of the multimarkdown binary exclusively…

If I’m double-checking its binary selection logic I rename the multimarkdown executable and replace it with a simple script that prints “test” to STDOUT. If you get a text file with “test” as its content then you know that is the binary Scrivener is using. :slight_smile:

Good to know the helper scripts are no longer a part of the distribution. I don’t believe we rely upon any of them anyway. In the specs I always used command-line toggles on the main executable.

Hm, replacing /usr/local/bin/multimarkdown with the following script:

#!/bin/sh
echo "test"

Set with the right permissions and that works at the command-line causes an immediate crash in Scrivener :open_mouth: Suppose that means Scriv is trying to use the installed multimarkdown… :wink:

Ha, well that’s one way to confirm at as well. Making the shell script executable helps. :slight_smile: That’s one to write up as a bug though, there should be no reason to crash because the launch path is not executable.

Then I made my own mistake—tried to turn this into BBCode with my MMD XSLT and got an error that “Test” is not a valid XML file. :smiley:

Ah, I set executable bit for user but not group and others (typo 766 rather than 755), should have just used +x…

I now suspect Scriv is not actually using system multimarkdown:

MMD 5 has a whitespace fix for footnotes (newlines are turned to spaces, which means MMD4 > LibreOffice would create a footnote like this¹ . The screenshot is a textdiff of Scrivener compile (right) to a commandline compile (left) of the same file. Note the newlines after the footnotes for scrivener vs the commandline. That suggests to me Scrivener although it looks for the system multimarkdown (thus the crash) doesn’t then use it?

I’m not sure what is going on there. It is overriding properly on my system, I just double-checked again. So for you it is showing the old MMD bug in multiple projects, yet when you do the “test” check you get the word “test” written to a file when compiling? I can’t think of why one would work and not the other.

Exactly, very weird indeed…

Not an issue as I normally export as MMD only and use a ruby script to customise the FODT XML, fixing a host of MMD > FODT bugs and glitches that annoy me.