"Convert Multimarkdown to Rich Text" Compile option failure.

As the title says. This one is perfectly reproducible, details below:

  1. Create an MMD reference-style web or image link in the middle of your text. Example: “[Google][1]”
  2. Put the actual MMD URL reference at the very bottom of your text. Example: “[1]: google.com
  3. Do not put a paragraph break at the end of the reference. In other words, let the ‘m’ in google.com be the last physical character in the text.
  4. Expected behaviour: The reference link compiles correctly, leaving a link to Google in the middle of your text.
  5. Actual behaviour: Varies depending on the text in question. Sometimes only the raw link pieces are left in the text, unprocessed. In others, all the Multimarkdown in the text is unprocessed, leaving the document as raw MMD.
  6. Workaround: Add a paragraph break to the end of the text. MMD is processed normally.

I’ll be happy to provide you with a (non-working) example if you like.

If each reference link needs to be on its own line, doesn’t the final link in a text need a paragraph break so that the compiler can identify the line correctly and compile the link appropriately?

So is this not actually acting as it should? I have always assumed this to be the case, but can see that I might be wrong. Or have I misunderstood the point?

shrugs. When I was programming, end-of-file was treated like de facto end of line for translation purposes. More to the point, the Markdown editor I’m using creates those reference links for me, and doesn’t put a final paragraph break at the end. All the other Markdown translators I’ve tried work with the references without a paragraph break after just fine.

I accept that L&L might declare this a “feature.” If so, I’ll need to check every file coming back from my Markdown editor to be sure it has a terminal paragraph break… Blah.

Hope someone form L&L can confirm this one way or another.



Both MMD and Pandoc handle links without any EOL just fine ( from the commandline, you can enter text directly to stadard input (STDIN), and press ctrl+d to start processing:

➜ multimarkdown
This is a [test][1] to see what happens.

[1]: https://google.com
<p>This is a <a href="https://google.com">test</a> to see what happens.</p>

➜ pandoc
This is a [test][1] to see what happens.

[1]: https://google.com
<p>This is a <a href="https://google.com">test</a> to see what happens.</p>

Thanks, this does look like a Scrivener-specific bug. I’ve tested with MMD-5 and MMD-6 (the former is what Scrivener uses internally for some conversions), and neither has any problem recognising syntax at the EOF.

Fixed for the next update.

Well, I was clearly wrong. Apologies.

It does need to be on its own line, but when it’s the last line, it doesn’t need a return after it. The problem here was how Scrivener converts everything to rich text - it puts all the various texts into a single monolithic text with tags between them, converts the lot, and then splits them apart again based on the tags so that it has a bunch of rich text documents to work with for Compile. The problem was that the internal tag was getting added right below the last line, rather than having an empty line between the last line and the tag. So this was messing up the conversion.

Thank you, Keith!

No need to apologise for being wrong! I’m often wrong. The only sin is not learning from it. For example, I struggled with this for weeks, not checking the reference links coming back from my Markdown editor, because “it can’t make any difference…”

Oops. :blush:

I’m delighted to report that this bug is fixed in Scrivener 3.2. On to EFS v Inline Annotations!