Tinderbox Forum

Summarizing outlines in $Text - working with relative $OutlineDepth

For a long time, I’ve been dealing in my mind with the pros and cons of “plain” outline structures versus topic outlines with their attached notes. Tinderbox works best with the latter (by assigning a $Name and a $Text attribute to each note), but I’ve been working with plain outlines for book and article annotations for quite some time (they’re kept in hundreds of OmniOutliner files I’d like to export to OPML and integrate in TBX).

Then recently I came to know the exportedString() function, and realized how easily I could work with both kinds of structures, by summarizing children notes in the $Text attribute of a “topic” note using a stamp or edict (i. e, $Text=exportedString(this, "/Templates/Annotations Outline Summary"); $ReadOnly=true;).

It makes sense to me to have all first-level children notes as separate paragraphs, and rarer lower-level notes formatted in a Markdown-compatible “list” format. I’ve almost had complete success, except that I couldn’t find a way to properly indent the list items for those lower-level entries.

I’ve tried ^indent("\t",^value($OutlineDepth(parent) - $OutlineDepth(current) - 1)^)^, but apparently $OutlineDepth(current) returns an empty value, and I end up with too many identation tabs. Am I misusing it? My understand was that current would designate the note where the stamp is applied to.

I would much appreciate some help! By the way, I think this trick might be of interest to many people considering moving from OmniOutliner to Tinderbox, or integrating them (I would have done it much before if I had realized this possibility).

The full export template runs as follows:

/Templates/Annotations Outline Summary:

^children(/Templates/Annotations Outline Summary/Outline item)^

/Templates/Annotations Outline Summary/Outline item:

^if(ChildCount)^^if($Prototype=="Quote")^> ^endif^^value($Name)^^if($loc)^ (p. ^value($loc)^)^endif^

^children(/Templates/Annotations Outline Summary/Outline sub-item)^

^else^^if($Prototype=="Quote")^> ^endif^^value($Name)^^if($loc)^ (p. ^value($loc)^)^endif^


/Templates/Annotations Outline Summary/Outline sub-item:

^if(ChildCount)^^indent("\t",^value($OutlineDepth(parent) - $OutlineDepth(current) - 1)^)^- ^if($Prototype=="Quote")^> ^endif^^value($Name)^^if($loc)^ (p. ^value($loc)^)^endif^
^children(/Templates/Annotations Outline Summary/Outline sub-item)^^else^^indent("\t",^value($OutlineDepth(parent) - $OutlineDepth(current) - 1)^)^- ^if($Prototype=="Quote")^> ^endif^^value($Name)^^if($loc)^ (p. ^value($loc)^)^endif^

$OutlineDepth(current) should not return an “empty” value. But, try

^indent("\t",^value(eval($OutlineDepth(parent) - $OutlineDepth(this) - 1))^)^

Hello @PaulWalters!

It didn’t work :frowning:

It seems that $OutlineDepth(this) in the template will designate the note currently being worked by the export process (not the one that was the target of the exportedString action in the stamp).

By the way, I checked, and $OutlineDepth(current) has an empty return even when enclosed by eval.


I don’t have problem with $OutlineDepth over here in templates. To simplify your testing try adding this line to a template

Outline Level ^value($OutlineDepth)^
Outline Level ^value($OutlineDepth(current))^

Over here, both formulations return the same value, and the value is always non-zero / non-empty.

Your formula is going to return a strange result for tabbing. If OutlineDepth(parent) == 1, and OutlineDepth(current) == 2, then your formula returns 1-2-1 = -2.

Why do you want to do that?

Anyway, this formulation works over here, so the problem is in your indent(), not in the value() calculation.

^value($OutlineDepth(parent) - $OutlineDepth(current) - 1)^

Hi, @PaulWalters. My idea was actually to calculate the depth relative to the main “topic” note (I thought that current would designate that note, which is the original target of exportedString, not the one currently being exported). Can we access that value somehow, or build the template differently?

I’ll copy an example of what’s happening. What I get are extra tabs because $OutlineDepths are absolute values in the document hierarchy.

Perhaps the ancestor designator would help.

Stepping back – it’s not clear from the OP why this complex export is needed. Perhaps it is too complex?

What is it you are trying to accomplish. I.e., what is the export going to be used for? Print? Distribute to someone? Import elsewhere?

Sorry, if I had time to propose a template that would answer the requirement I would – perhaps another reader has a thought?

The idea is to handle outlines I’m used to take with OmniOutliner, which are structures more or less like the above (the above in particular being somewhat complex and unusual anyway). Tinderbox of course enforces giving a $Name to a note, and assigning contents to a $Text attribute.

This has prevented me some years ago from adopting TBX, as I usually prefer building and rearranging the annotations as my reading progresses, eventually naming a topic and assigning it tags related to my research projects. Most of my existing outlines are like this:

I am now more tempted to adopt a two-stage approach with annotations, converting subrows to what in OmniOutliner jargon is called the “note” attribute of a cell, the equivalent of $Text in TBX (I’ve written a script for this purpose):

However, I can do the same thing inside TBX, collecting the $Names of sub-items and putting them in the $Text attribute of the relevant note (where $Name is actually a meaningful thing, naming the topic contained by its sub-notes). That would allow me to simply import my existing outlines as they are and deal with the relevant top-level notes with a stamp. The technical point being that TBX’s interface isn’t exactly smooth with long $Names for notes, as it was designed expecting extensive textual content to go in a $Text attribute.

But, to mention, the real interest in all this, and where TBX truly excels, is that I can collect appropriately tagged notes – including my own ideas, not only annotations from my bibliography – by means of Agents, using a $Tags.intersect($SearchTags(agent)) query. Those are “topic agents”, organized in an outline, corresponding to all different research subjects in a project, as they emerge. Having this analytical view of the research material is a real game changer, for as research progresses it becomes increasingly difficult to gather the material in a meaningful way (at a point in the final stage of writing my Ph.D. dissertation, I had to stop for a couple of weeks just to organize what I had, cutting pieces of outlines into text-formatted notes then-stored in DEVONthink – a solution that was roughly satisfactory).

I don’t know if my description was clear, but it tries to give a testimony on the way I’m working with TinderBox for this kind of notes :slight_smile:

As for the immediate problem with $OutlineDepth, though, I think I can live with a hard-coded calculation of where those topic notes from annotations normally reside in the document structure, and make ad hoc adjustments if needed.

1 Like

@PaulWalters I think I figured out why you’ve got surprised with the approach described. After reading some posts in the forum (particularly this one), I realized I was underestimating the power of the “Preview” panel (perhaps because its name is quite misleading, what it does is really a “rendering” of notes, not necessarily previewing how they’d look like if exported from Tinderbox).

Apparently I can have a much simpler setup creating an HTML “export” template appropriate for “previewing” (sic) those notes, and using <li> tags (which don’t require indenting anyway) for sub-sub-items. Then there’s no need to mess with $Text contents.

/Templates/HTML Annotations page:

<!DOCTYPE html>
	<meta http-equiv="content-type" content="text/html; charset=utf-8">

^children(/Templates/HTML Annotations page/HTML item)

/Templates/HTML Annotations page/HTML item:

<p>^if($Prototype=="Quote")^<blockquote>^endif^^title^^if($loc)^ (p. ^value($loc)^)^endif^^if($Prototype=="Quote")^</blockquote>^endif^
^children(/Templates/HTML Annotations page/HTML list item)^

/Templates/HTML Annotations page/HTML list item:

<li>^if($Prototype=="Quote")^“^endif^^title^^if($Prototype=="Quote")^”^endif^^if($loc)^ (p. ^value($loc)^)^endif^
^children(/Templates/HTML Annotations page/HTML list item)^

I guess I could also build a very generic HTML template, testing for $Prototype=="Annotation" or ^if($Text=="")^, but simply assigning the special template in those notes’ prototype should be sufficient by now.

1 Like

Glad you liked the article. Sounds like it had the effect I wanted, calling to your attention the power of templates and preview. Nice work yourself.

I realized I was underestimating the power of the “Preview” panel (perhaps because its name is quite misleading, what it does is really a “rendering” of notes, not necessarily previewing how they’d look like if exported from Tinderbox).

If we didn’t call the panel the Preview panel, what would be better, that would demystify its use especially for new users? Webview? Powerview? RenderView?

The point is, as I use it it’s not really a ‘Preview’ of anything, it’s The View. I really just want to see it just like that.


But the panel is definitely a preview. It is a preview of how notes look when export code templates are applied, or markdown using an $HTMLPreviewCommand appears. I am not at all in favor of renaming the tab – its name is sufficient. One doesn’t need the intent to export in order to benefit from a preview. The suggested alternate names for the panel are confusing, IMO.

Offering a preview is certainly one of the things the Preview Panel does, and clearly, as indicated by the name, that was its original intent, when Tinderbox was created as a blogging product. But I, for one, have never used Tinderbox to blog, or to make a website, and I likely never will, because I don’t do that sort of thing. What was intended as a a ‘nice to have’ side-effect, or debugging tool, WebView, is now the main event, though, because of how most users use it (aTBRef and a couple of other exceptions aside.). I don’t even really use it to preview a print, because I don’t print from Tinderbox, ever that I can recall.

I don’t like any of the names I came up with, either. But it’s not a PREview. It’s a view, period. It’s not ‘prior’ to anything, it’s an end product.

However, Tinderbox is not the only app to use the nomenclature. So does Ulysses.

It’s not the right name there, either. It’s not a preview of a coming attraction. It’s the show.

1 Like

I agree that a name change to convey the possibilities of the “Preview” panel would be difficult (not only because it is not clear how it could be alternatively named, but also because of the incoherences it would produce with the nomenclature of internal variables).

Most important is to adequately present its actual powers to new users. I was unable to realize it when reading the documentation. With the added benefit of a beautiful responsive stylesheet (symonlc’s Markdown.css) I can now make a much deeper sense of my notes inside TBX. I have actually more often reversed my strategy, doing input of my writing in TBX, and then exporting the final results to OmniOutliner via OPML just to keep a record (being it accessible on the iPad etc.). I’m liking more and more to work in this way.

1 Like

Bruno, would it be possible to post a sample file ? My understanding of TB is rudimentary, especially exporting/HTML preview. How does TB provide a deeper understanding of your information vs omnioutliner ?

1 Like