Quick setup for markdown preview

Exporting from Tinderbox
1

I have understood the posts in this forum about selecting the notes to export. At this stage I don’t want to export notes or mess with output options. I would just like to preview markdown in the Preview Pane.

I suspect that must be very simple, but I have been unable to find how to do it. I detail below what I have done so far.

  • I have duplicated the default HTML page in the templates folder, and named it tMarkdownPandoc page, with this content in $Text:

      ^title^
  ^text^
  ^children(/Templates/tMarkdownPandoc page/tMarkdownPandoc item)

  • I have duplicated the default HTML item as tMarkdownPandoc item, and placed it as a child of the former. Its content in $Text is:

    ^title^
    ^text
    ^children(/Templates/tMarkdownPandoc page/tMarkdownPandoc item)

  • I have created pMarkdownPandoc in the prototypes folder and entered into its $HTMLPreviewCommand /usr/local/bin/pandoc. I have assigned to it the default Markdown prototype. I have assigned pMarkdownPandoc as the prototype for tMarkdownPandoc page and tMarkdownPandoc item.

  • In the HTML inspector I have marked notes to be exported, and tMarkdownPandoc page as template.

Surely there is something wrong above. Do I have to change Markup, Style and List settings in the HTML Inspector as well?

2

There is a simpler way. See

http://www.acrobatfaq.com/atbref7/index/MiscUserInterfaceAspects/Markdownpreviewrendering.html

And

http://www.acrobatfaq.com/atbref7/index/MiscUserInterfaceAspects/Built-inPrototypes.html

And

http://www.acrobatfaq.com/atbref7/index/Attributes/SystemAttributeList/HTMLPreviewCommand.html

And the v7.2 release notes

3

Paul, I am trying to set it up even for basic previewing because the simpler way doesn’t seem to work.

I’ve created a new tb document. I downloaded the Markdown prototype; no export template is defined, according to Markdown preview rendering.
TB uses the markdown distribution inside the Tinderbox app, according to Built-in Prototypes. Therefore, there is no need for me to set a path to an alternative processor according to HTMLPreviewCommand

My note is not previewed well in markdown, not even __word__ or **word**. So I think trying a simple setup is the way to go, if I want to be able at least to preview notes in markdown.

4

Works for me (v7.3.1):

  • Open a new doc.
  • Add the built-in ‘Markdown’ prototype. (There’s nothing to download, you’re simply copying a prototype stored in the app).
  • If not showing use the Window menu to show the text pane tabs (Text/HTML/Preview).
  • Add a new note and give it some text ($Text) that includes some Markdown code.
  • Set the note’s prototype to use “Markdown”.
  • Select the ‘Preview’ tab of the text pane. Your text is rendered using Markdown, no HTML template required.

As you don’t explicitly mention it, it may be you’re missing the penultimate step. For a note to use a prototype, the note must be set to use the prototype which can be done in many ways. Just having the prototype in the document isn’t enough as it simply means it is available to be used by other notes.

1 Like
5

Here’s all you need do:

1124×428 915 KB

Click on the GIF to embiggen it.

Nothing here requires an export template. With the $HTMLPreviewCommand set as shown, markdown preview “just works”. (The “Markdown” prototype is useful but not needed either, just the $HTMLPreviewCommand as shown.)

1 Like
6

@mwra. [quote=“mwra, post:4, topic:1033”]
Set the note’s prototype to use “Markdown”.
[/quote]

This is the step I was missing. Thank you for the gif as well, @PaulWalters.
I have set Markdown now for the note’s prototype (pNote), so I don’t I have to keep repeating the operation. Perhaps I will set it in the Inspector as the system default.

7

You can do that for a document, but not as a “system default”. Also, so as not to limit any other prototypes you might create in a document, I suggest setting the “Markdown” prototype – once you’ve added it to a document – as the prototype for all other prototypes. Thus, by inheritance, the settings in the Markdown prototype are inherited by all your other prototypes.

(Yes, prototypes can have prototypes of their own.)

1 Like
8

I would have thought that assigning Markdown to all prototypes would create problems for the HTML Template prototype or for modified Markdown prototypes I create, wouldn’t it?

Preview is working fine with Pandoc. I think not for fotnotes or http URLs (I don’t need them here) but it does work with DEVONthink URLs.

9

It shouldn’t. The HTMLPreviewCommand affects Preview, not the exported HTML. Setting a value for that attribute is all the Markdown prototype does.

1 Like
10

Good to know, thanks. I was actually planning to set $HTMLDontExport to true in most prototypes. But it might be better to do it on folder basis.

I have noticed that markdown in $Text doesn’t render in map view. Not a big issue, but I mention it just in case @eastgate thinks it is easy and worthwhile to correct it.

11

Nor would I expect it to. Preview is essentially the (html/formatted) export in rendered form. Markdown mark-up is only processed on export, or internally previewed [sic] via the preview tab.

Meanwhile, in map view, _if_a note icon is big enough and if the note is set to display body copy (by default, it is) it displays the RTF [sic] of text. Actually not quite all RTF, for instance all text is drawn in the same colour even if the text contains coloured text.

I think the misconception here is that Markdown is used for internal text rendering. If you want to make a feature request for that, email Eastgate with your use case. Having watched the app’s development over the years, $Text has moved to being an RTF [sic] space. Going to plain text + Markdown would effectively fork the text pane design so I suspect might be more complex to ‘correct’ than assumed. As a lot of people ‘live’ in RTF and never use export a full change to a plain text+Markdown would also inconvenience many.

12

It’s good to have both options. Unless the markdown editor became something like Typora’s, I find it convenient the way it is now. Though markdown should be a better file format for preservation.
For the time being, I better improve my knwoledge of what TB already has to offer. :blush:

13

Markdown was added, very recently, to help with export. The textual space has moved more heavily to an RTF writing space (as opposed to a coding space) since the v6 re-design. My reading of the latter is that is what (most?) users were pushing for.

If you’re writing notes for internal use, I’d suggest not trying to use text with mark-up if you want to read it right through the app as you’ll be fighting the design. Tinderbox is a toolbox for notes as opposed to a coding IDE. Whilst maps, timelines, etc. are very visual it’s most useful to think of Tinderbox as a place to write and analyse textual information. If you start from that premise you’re likely to start with fewer mis-assumptions about how things work. HTH.

1 Like
14

I have a very different view to @mwra’s. I think it is a fine use case to view rendered text in Preview and never export it. This happens to be my use case, FWIW. And, backstage, I lobbied for this feature, so I’d like to think that helped influence why $HTMLPreviewCommand came about as a Preview but not an export feature.

The attribute affects nothing about exporting. FWIW, if one wants to export markdown text, it is best to export the plain text and then use Marked or other software to render it. (I’ve posted tutorials on the old forum explaining that.) Marked is more feature rich for markdown rendering than Tinderbox can be without considerable heavy lifting.

(There are other ways to get markdown exported, but that’s not the topic of this thread.)

@jmm’s point about map’s not displaying rendered text is a good one – and I think the limitation is that Maps are not previews, and making them act that way is perhaps a bridge too far.

15

In a personal use perspective, I’m actually with @PaulWalters’ opening comment above. My previous comments were in my community hat, trying to stop another new user starting off with incorrect assumptions as to how the app is designed. In doing so, I’m not arguing for the status quo but explaining what a new starter will encounter today. To the person with a hammer, everything can look like a nail. It can be painful to watch, thus the point about this being a toolbox - i.e. i.e. there are screwdrivers, wrenches, etc. - not just hammers.