How do I fix my ziplinks to appear as links in markdown preview

Perhaps I’m thinking about this wrong, but doesn’t that depend on where the export is being hosted on the server? For example if it’s hosted at the server’s root (“/“), the exported links will be correct, as you noted. However, if the export is hosted in a subdirectory (“/blog/”) the links will not work. But I suppose you could “tweak” TBX’s export to be aware that the resulting HTML files will be hosted under (“/blog”).

It seems like the safest behavior is to export relative links so that the resulting HTML can be hosted “anywhere.”

Thank you, @eastgate and @mwra for investigating this issue.

Yes, but note the point this misses is this is a weakness in Markdown but not Tinderbox. HTML export from Tinderbox works fine. For Tinderbox to export relative notes just for Markdown users needs to show and ROI on the engineering needed, noting that Markdown is a niche use of Tinderbox as whole. Put another way, facilities are finite. Fixing an edge case for Markdown needs to be considered in terms of its utility to Tinderbox users as a whole, of whom only some use Markdown.

That said, if a note has an $HTMLPreviewCommand value, is that an unambiguous marker of Markdown-centric use. Again, if so, then could ^text^ evaluation in such a context could, when using $Path data, behave differently from default ^text^ use and omit the opening / in the $Path data?

Why do so? See @JacobIO’s user function() code up-thread which does the same by a brute-force regex change and that seems to fix the issue.

Thus there might be a simple fix at hand, albeit a kludge that later evolution of Markdown flavours might break, but which doesn’t hit the ROI issue raised at the start of this post.

†. Not investigated in detail but I’ve a hunch that approach might itself throw up some unintended edge cases of unintended mis-interpretation and thus erroneous regex replacements.

As a seasoned technology leader, I understand that and I’m not requesting that @eastgate make any changes to the Markdown “export” behavior I’ve observed. Moreover, as you pointed out, I’ve developed an effective workaround that works for my use case that I’m happy with.

FWIW, as I’ve been working to s setup my innaugeral TBX document, I’ve encountered a couple repoducable actions that crash TBX. Should those be reported here, on the forum, or through some other means?

Noted. I’ll “burn” that bridge when I get to it :wink:

1 Like

BY email to tinderbox@eastgate.com or bernstein@eastgate.com, thanks!

Thanks for the summary and kindly sharing your function to fix the URLs for Markdown work.

I suspect you know where to find these, but for lurking readers of the thread, see Where are crash and hang logs found?.