Tinderbox Forum

Export values in Markdown

I am attempting to show $Created in a note’s Preview and in its HTML export. I use ^value($Created)^ in $Text, and this works fine… for a regular note.

The problem arises when I want to write $Text in Markdown. I applied the built-in Markdown prototype to the note. Using ^value($Created)^ no longer generates the desired effect in Preview or in the HTML export.

Is there another way to export values when the note is set to use Markdown?

I hope my question is clear – my terminology seems incorrect, or at minimum clunky.

Could you post a small TBX showing the problem (don’t forget a note in it telling us how to find/see the problem) so we can reproduce the issue and test?

The code currently view Markup (and other HTMLPreviewCommands) as an alternative to interpreting Tinderbox markup elements.

Offhand, I don’t see why we shouldn’t interpret these elements before handing the interpolated text over to markup. But the code has the hallmarks of a situation where I was avoiding an obvious pitfall. I don’t see it, but I’ve been doing fiendish geometry for about 14 hours at this point; does anyone see a reason NOT to do this?

1 Like

I like this suggestion: TBX pre-parses and then hands off to other markup.

A consideration is that the carrot symbol is used in multi-markdown (MMD) syntax for footnotes. That has to be handled with some care when pre-parsing. I don’t think it’s a big deal – in MMD, the syntax is [^footnote], which is sufficiently different from ^value()^.

1 Like

fwiw, this was what I was hoping for with Markdown support. I like using Tinderbox for making links in particular, and I was hoping that links would exported as part of Markdown. Unfortunately they’re not right now.

I’m not sure where you draw the line – do you export italic text as <i>italic text</i> like you would with an ordinary HTML export? I think that would be cool, but then how do you handle # markdown headings?

Some sort of combination of Tinderbox processing + markdown preview would be powerful – at the very least, rendering Tinderbox links and export code prior to passing it to the markdown preview binary.

If Tinderbox were pre-processing export code, that’s easily worked around by a long-standing convention whereby a caret (^) is escaped by doubling it. IOW, ^^ in $text renders as ^ in the output. Thus an MD citation would just need a double caret so it ‘survives’ Tinderbox export code processing.

MD is a cool technique, but I’d argue that any accommodation shouldn’t break existing HTML export as that would favour the needs of the few rather than the needs of the many, especially as in this case the ‘few’ are more technically adept: MD is hardly what the lay person sues and many of our fellow users aren’t techie folk.

Nothing, as far as I’m aware. I’m simply suggesting that any resolution to this shouldn’t. :slight_smile:

Yep, HTML is valid markdown.

My comment is concerning some of Tinderbox’s built-in processing. For example, the note:

# funky
# chicken
# so cool

for a standard HTML note would become:

<li> funky
<li> chicken
<li> so cool

but for a Markdown note is:



<h1>so cool</h1>

So, I would definitely like to see some of Tinderbox’s built-in processing be maintained – e.g. bold text becomes <b>bold text</b>, and links get exported (most important to me) – I’m simply pointing out that some care needs to be taken in doing this, because some of Tinderbox’s syntax conflicts with some of Markdown’s.

One problems with supporting that is it would (might?) mean the end of Tinderbox’s long-standing quicklist method. As the RTF engine in the $Text space doesn’t seem to support nested lists, I’d not support changing HTML export processing as it lists. Plus I’d have to manually check and fix 1000s of notes. So, I guess I’m not a great supported of ‘full’ MD support if it means it breaks exports from my 100s of TBX files.

That’s not to be confrontational. I just wonder, for the engineering cost involved, what % of users will benefit vs those (many of whom have little understanding of HTML detail) whose export will now break and so needs lots of support to train on an even more obscure* mark-up system.

*point being, that Markdown isn’t very mainstream. Whilst I see it’s benefits and indeed use it daily in the forum for mark-up in posts, I work in a lab full of web-centric researchers and many don’t know MD other that it being an alternative mark-up.

If we can have both, great. If existing HTML and Tinderbox export mark-up use needs to be borked just to favour easy Markdown, then my 2¢’s vote is against it. That’s my personal view, I want make clear my moderator/tester role doesn’t privilege my voice over that of any other Tinderbox user.

This is the exact point that I’m (unsuccessfully?) trying to make. While I would love to see more of Tinderbox’s features applied to exported Markdown notes (links! it’s always about links!! :slight_smile: ), I don’t think it’s as simple as “run Tinderbox’s normal export process and then pipe it to markdown,” because Tinderbox and Markdown use some of the same syntax to represent different things. I used the quicklist as one example, where it may be difficult to divine the author’s intent – do they want a Tinderbox quicklist, or a series of HTML headers?

That is just one specific syntax example, maybe there are others, I’m not sure. In any case, if eastgate has any interest in making Markdown export richer, they will need to account for the interplay between Tinderbox export syntax and Markdown syntax.

Well, anyone who posts on this forum is using Markdown :slight_smile: It might be more common among the Tinderbox user community than you suspect.

But let’s not overlook that most people use little/no mark-up and the basics are offered by buttons. Thus it’s easy to over-estimate deliberate usage (i.e. choice/expertise).

But this isn’t be a matter of whether mark-up method X is better/worse, but its intersection with existing functionality and there I think we’re all on the same page.

That’s an interesting point. I wasn’t even aware that # can be used in this way in “standard” Tinderbox to generate an enumerated list. Very cool, and it does raise an important point. Certainly, to @mwra’s point, accommodating Markdown should not break existing TBX documents and behaviors.

Having said this, my understanding is that notes would undergo what we’re been talking about — pre-parsing and subsequent hand-off to a Markdown converter — iff the note is actively assigned a special prototype, such as the built-in Markdown prototype. Otherwise, standard export rules apply.

If I’ve understood this correctly, the things we’re talking about here would not affect existing notes unless the user switches the note to employ Markdown export. The remarkable flexibility of TBX continues to impress.

1 Like

Is Tinderbox mainstream? I think, MD is getting very popular these days. Look at Bear Writer, Drafts, Ulysses, Trello, iA Writer etc.
And by the way… waaay easier to learn than TB. And also easier than HTML.
Especially for hacking some notes into the computer, I think, there is no easier way than using MD. You don’t need to fiddle around with the mouse for some basic structure… simple and fast

I prefer MarkDown and do nearly all my writing as well as my presentations in MarkDown applications. It is a joy to not have to muck about with formatting and layout in applications like Word.

Resurrecting this thread to see if there are any developments. I’m still very interested in using Export Codes to publish note-specific values in Markdown. Absent this feature, using Markdown means giving up all of the powerful TBX export features… it feels, to me anyway, a Hobson’s choice.

My read of this thread suggests that the solution you proposed could work. If I attempt to summarize, the approach is:

  1. the default would be to treat $Text as RTF. Users would have to activate an attribute to trigger Multi-Markdown conversion. This prevents any negative effects on existing notes that use RTF, or on users who prefer to continue to use RTF.

  2. For notes on which MMD conversion is turned on, Export Codes (including those for links!) would be pre-parsed, and subsequently handed-off to MMD converter.

I’m wondering if this is technically and philosophically in line with TBX development to be on its near-term(?) roadmap.

Yes: much of this is implemented in the current backstage release, and more is coming in the next backstage release. Reconciling some of the interactions has been tricky!