Table of Contents inside a tiddler

[Stephen Kimmel]

I use Tiddlywiki at work. I work with a lot of documents of different types. Some are legal documents and affidavits. Others are contracts and specifications. Some are well structured while others seem to ramble pointlessly. Some are lengthy while others are very short. I need to be able to figure out quickly which document contains a particular requirement. I've found that Tiddlywiki with its search function, and especially with Danielo's context search plugin, is almost perfect for my task.Everyone I've shown my wikis to has been envious.

One key criteria in my line of work: for existing documents, I must have every word and character correct and in the right order. Most of these documents must not be edited. For example, I can't change any part of an existing contract. I can highlight portions of it but I must not change any word or word order or punctuation mark. Using a clause from one document in another is rare enough that simply copying is the obvious answer.

Consider the two alternate ways of doing things; the preferred Tiddlywiki method of breaking my documents into small pieces and my current method, the document dump.

I don't so much create tiddlers as dump documents into them. Dumping a document into a single tiddler is fast and easy. Open the word document. Copy the entire thing. Open the wiki. Create a new Tiddler. Paste the document into the tiddler. Name the tiddler to match the source document name. And I'm done. If I care to preserve the formatting, I add three quote marks at the beginning. Total time expended, perhaps a minute. If I really want to make it pretty, I can spend 10-15 minutes adding exclamation marks to mark headers or use Danielo's Keysnippet routine to convert some jumbles into neat tables.

This creates what can be a very large tiddler. The search function works as expected and rapidly identifies which document contains which phrase. It has every character and every word in exactly the right order. It accomplishes what I need to accomplish with a minimal amount of effort.

And the disadvantage? So far I haven't found one. If Tiddlywiki processes the tiddler more slowly, I haven't noticed.

By comparison, the Tiddlywiki preferred choice, lots of little tiddlers, is a good deal of work.

I've tried copying and pasting individual segments from the word document into individual tiddlers. Each smaller tiddler takes about the same amount of time to set up as my much larger single tiddler but after that I'm still not done. I still have to rebuild the original document from those individual tiddlers and I have to verify that I got all the material correctly. When that is done, I have to create a field and tagging system so that each smaller tiddler will reflect its source document and sort correctly so the table of contents will be right.

If I saw any real advantage to using a lot of little tiddlers to accomplish the same thing that can be done with one large tiddler, I might go ahead and spend the extra time. The last couple times I went through this exercise, it took me hours rather than minutes. And what did I get for my effort? As close as I can tell, nothing but older.

One thing that would make my life easier would be a table of contents that worked inside a single tiddler that was based on headers or some invisible marker. I know this has been requested more than once and now, perhaps, you can understand why I want one. A simple list of headers would be helpful. I could then use the browser's Find command to jump to the appropriate section.

[Danielo Rodríguez]

Hello Stephen,

Consider installing Match filter from Eucaly's Tiddly World: http://eucaly-tw5.tiddlyspot.com/#%24%3A%2Fplugins%2Feucaly%2Fmatchfilter%2Freadme

Then you can do cool thing such as:

\define regex-feature-header() (^!+.*)(?gmi)

<div class="TOC"

<$list filter="[all[current]match:text<regex-feature-header>]">

<li>{{!!title}}</li>

</$list>

</div>

!!!title

!!!other title

Some css for changing how the headers looks like inside the TOC div should do the trick.

Let me know if this fits your needs.

[Danielo Rodríguez]

.TOC h2 {
font-size:50%;
}

.TOC h3 {
font-size:25%;
}

[Stephen Kimmel]

\define regex-feature-header() (^!+.*)(?gmi)

<div class="TOC">

 

<$list filter="[all[current]match:text<regex-feature-header>]">

 

<li>{{!!title}}</li></$list>

</div>

works far better than I expected so soon after I posted my issue.  I am having some problem with the css code. It looks as though {{!!title}} takes the entry strictly as text. So in this example, I'm getting

• !!!title
• !!!other title

[Danielo Rodríguez]

Hello remove the <li> marks. That way the text will be wikified and you will keep the hicherachy of the document. Then all you have to do is to adapt the text size for h1..hn within the div TOC.

[Stephen Kimmel]

Hello remove the <li> marks. That way the text will be wikified and you will keep the hicherachy of the document. Then all you have to do is to adapt the text size for h1..hn within the div TOC.

Maybe I'm just exceptionally dense but making  the code

<div class="TOC">

<$list filter="[all[current]match:text<regex-feature-header>]">

{{!!title}}</$list>

</div>

gives me

!!!title !!!other title

[Tobias Beer]

Hi Stephan,

perhaps try..

<$view field="title"/>

instead of...

{{!!title}}

Tobias.

[Birthe C]

Hi Steffen and Tobias
I get the same result in both cases. And that result is:

!!!title !!!other title

And under that I get the list with the font-sizes I wanted. (I used Danielos suggestion)


Birthe

[Danielo Rodríguez]

Maybe I'm just exceptionally dense but making  the code

<div class="TOC">

<$list filter="[all[current]match:text<regex-feature-header>]">

{{!!title}}</$list>

</div>

gives me

!!!title !!!other title

Some times small details drives us crazy. Try adding some carriage returns so the text is wikified:

[Danielo Rodríguez]

Sorry, I mean add them before

[Tobias Beer]

Hi Danielo,

 

Some times small details drives us crazy. 

Try adding some carriage returns so the text is wikified...

Huh? o.O

That shouldn't be the case though, should it?!?

I smell bug-meat. Let's gobble that down! ^_^

Best wishes, Tobias.

[Stephen Kimmel]

That did it. Thanks. Now let me see where I can go with it.

This sensitivity to carriage returns seems to be something we acquired when we moved from TWC to TW5. I wouldn't call it a feature but it does appear to be an intrinsic part of the design. As such, it is probably not a bug but an ongoing inconvenience.

Thanks again, Danielo

[Danielo Rodríguez]

@Kimmel,

Glad you get it working. Let us know if you end up with something pretty and useful.


To @Tobías and @Stephen, take in account that TW can render text in inline mode and in block mode. There are tags that should be rendered in block mode in order to work. The headers are that kind of tags. On tiddlywiki the mode is determined by several factors, one of them is line breaks. Sadly line breaks are non visible. Please don't claim so high because this, there are many other languages where non visible characters are very important. Phyton is one of them and is one of the most popular languages.

Regards.

[Stephen Kimmel]

Glad you get it working. Let us know if you end up with something pretty and useful.

I don't know how pretty the results are or if anyone but me will find this useful but here is what I ended up with.

As Danielo suggested: I added $:/core/modules/filters/match.js from http://eucaly-tw5.tiddlyspot.com/#%24%3A%2Fplugins%2Feucaly%2Fmatchfilter%2Freadme ... Eucaly's site has a number of interesting plugins and examples that make it well worth lingering.

The main tiddler, which I named My ToC contains this code, which is some minor modification of the code Danielo suggested:

\define regex-feature-header() (^!+.*)(?gmi)
<div class="box">
<h2><u>Table of Contents</u></h2>
<div class="TOC">
<ul style="list-style-type:square">

<$list filter="[all[current]match:text<regex-feature-header>]">

<li>

{{!!title}}
</li>
</$list>
</ul>
</div>
</div>

I also have a file called $:/_tw5.com-styles which is tagged with $:/tags/Stylesheet and $:/tags/stylesheet so I use it in both newer and older versions of Tiddlywiki. That contains the following

box { display:inline-block; -moz-border-radius: 10px; border-radius: 10px; padding:0.1em 1em; background-color:#ececec; }

.TOC H1 {font-size:100%; font-weight: bold; line-height: 80%;}

.TOC H2 {font-size:100%; text-indent: 15px; line-height: 80%; }

.TOC h3 {font-size:100%; text-indent: 30px; line-height: 80%; }

.TOC h4 {font-size:100%; text-indent: 45px; line-height: 80%; }

.TOC h5 {font-size:100%; text-indent: 60px; line-height: 80%; }

.TOC h6 {font-size:100%; text-indent: 75px; line-height: 80%; }

I chose the font-size to force the wikified '!' headers into a constant size. Text-indent pushes the subheaders out to the right depending on their level while the line-height reduces the double spacing a bit.

I transclude the tiddler with: <$transclude tiddler="My ToC" mode="block"/> The table of contents will appear wherever you put the $transclude line and ends up looking something like this:

 

Table of Contents

• How I created my In Tiddler Table of Contents:

• Main Subject

•     First Subheader

•         title - Level 3

•         other title - Level 3

•             A title four levels

•                 Fifth Level

•         Back to third

•     Here's another header - Level 2

in a grey box with rounded corners.

Obviously this could use improvement and I'm certain some of our clever folks could code it much more tightly. Still, it accomplishes what I wanted.

[Danielo Rodríguez]

Nice! The important thing is that it works for you. Anyway looks great and sire it looks greater on your wiki. Thanks for sharing it back.

[Tobias Beer]

Nice! The important thing is that it works for you. Anyway looks great and sure it looks greater on your wiki. Thanks for sharing it back.

 Curiosity has me ask if that's anywhere to be seen. ^_^

Best wishes, Tobias.

[Stephen Kimmel]

Curiosity has me ask if that's anywhere to be seen. ^_^

Ask and ye shall receive:

https://dl.dropboxusercontent.com/u/6651245/My%20ToC.html

Suggestions are welcome

[Tobias Beer]

Thanks Stephen,

https://dl.dropboxusercontent.com/u/6651245/My%20ToC.html

I'll play around with that a little.

[Danielo Rodríguez]

Did you tried to make the toc smaller and float left ?

Also it's better if you use triple ticks to enclose the code on the explanation.
Regards

[Tobias Beer]

Did you tried to make the toc smaller and float left ?

http://tidtoc.tiddlyspot.com/#GettingStarted ;)

Best wishes, Tobias. 

[Danielo Rodríguez]

Very nice! I have to check it on my desktop computer to give you an opinion, but I like how it looks on my mobile too. Finally we gave a solution to all those people asking for a TOC.

Regards.

[Tobias Beer]

Very nice! I have to check it on my desktop computer to give you an opinion, but I like how it looks on my mobile too. Finally we gave a solution to all those people asking for a TOC.

Actually, I think I'll be satisfied once I managed (to hire a crew to help me) to port SectionLinkPlugin to tw5. ;) 

Despite any dreaded performance concerns, there are just too many highly useful usecases involved with sections...

• section-toc for tiddler foo, providing clickable links! (even back to the toc from the heading)
• $link to section foo, from tiddler bar, too
• $list section foo of tiddlers tagged bar
• (edit section foo)

Best wishes, Tobias.

[David Gifford]

I was JUST going to say that myself, that it is handy in and of itself, but what is really needed is the ability to create links to the sections within the toc.

[Danielo Rodríguez]

Hello David,
That's pretty easy with the use of links and anchors. I have plans to update my keyboard plugin so it will be very easy to create links to navigate to.

Regards.

[Jeremy Ruston]

> I was JUST going to say that myself, that it is handy in and of itself, but what is really needed is the ability to create links to the sections within the toc.

> That's pretty easy with the use of links and anchors. I have plans to update my keyboard plugin so it will be very easy to create links to navigate to.

I think making the internal TOC entries link to their corresponding heading may actually be quite tricky. Using links and anchors will only work for tiddlers that are only displayed once. Transclusion or use of sidebars could cause multiple headings to appear with the same anchor name.

>  Despite any dreaded performance concerns, there are just too many highly useful usecases involved with sections...

> section-toc for tiddler foo, providing clickable links! (even back to the toc from the heading)

> $link to section foo, from tiddler bar, too

> $list section foo of tiddlers tagged bar

> (edit section foo)

That implies making sections behave exactly like tiddlers. That's problematic because it means that all the behaviours we've built for using and manipulating tiddlers need to be re-engineered to work with sections. In some cases that's extremely tricky.

For example, how would you make a location hash link to a section (eg http://example.com/#my-section-12)? There's no syntax within the location hash to identify the string as being a section name and not a tiddler title.

Another example, to use the $list widget to list all sections of tiddlers tagged bar would require us to be able to process section names within filters. That implies that sections would need unique IDs - once again, making them meet the definition of a tiddler.

Basically, TiddlyWiki is a mechanism for manipulating tiddlers. Everything about it is predicated on the idea of a tiddler as the smallest unit of content. Your requirements describe something else: a mechanism for manipulating sections of monolithic hierarchical documents.

I understand why these requests are framed in terms of implementing sections but I'd really like more insight into the underlying needs. Is the desire for tiddlers with long, hierarchically structured content because they are easier to edit as a single run of text? Or easier to import? Or is it because the single tiddler is easier to read on screen than a sequence of tiddlers?

Best wishes

Jeremy.

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.
For more options, visit https://groups.google.com/d/optout.

--

Jeremy Ruston
mailto:jeremy...@gmail.com

[Stephen Kimmel]

I understand why these requests are framed in terms of implementing sections but I'd really like more insight into the underlying needs. Is the desire for tiddlers with long, hierarchically structured content because they are easier to edit as a single run of text? Or easier to import? Or is it because the single tiddler is easier to read on screen than a sequence of tiddlers?

I addressed some of those issues in the post that initiated this chain. Ultimately, in my case, it comes down to being easier to import. Easier to read or easier to edit are secondary considerations.

The documents I import and work with in Tiddlywiki can be quite long. Generally I reference them rather than edit them. Generally I must not edit them beyond highlighting a passage. As such, the process of splitting one of these documents into minimal sized tiddlers is laborious and counter-productive since it doesn't create much benefit that I've noticed.

The internal Table of Contents gives a quick overview of the document. While being able to jump to a specific section would be useful, I think the simple listing of headers is enough of an improvement for what I do with the tiddlers to be worth the effort. If the jumps can be accomplished easily, then fine. I am no expert but every time I've tried using anchors in the new Tiddlywiki, it has failed spectacularly. The best idea I have on how to accomplish it without anchors would be something like the browser's search function. Select the header, then search through the tiddler until the program comes to the matching string and then move the display so that the found string appears on the string. That is beyond my programming ability and so for the moment, I'm happy with the listing of headers that I have.

[Stephen Kimmel]

Tobias and Danielo,

It does look nice but I had one additional thought on this. At the moment, in my version, the background color for the box is hard coded in the CSS. It would be nice if it could automatically use the appropriate color from the selected palette. That seems like it ought to be as simple as knowing the right internal name to use...

[Tobias Beer]

Hi Jeremy,

 

I'd really like more insight into the underlying needs.

Glad you asked. Allow me to try and answer... :)

https://groups.google.com/forum/#!topic/tiddlywiki/23PzU2qCsj4

Best wishes, Tobias.

[Tobias Beer]

Hi Stephan,

I did an update and now use the tiddler dropshadow instead.

 

It does look nice but I had one additional thought on this. At the moment, in my version, the background color for the box is hard coded in the CSS. It would be nice if it could automatically use the appropriate color from the selected palette. That seems like it ought to be as simple as knowing the right internal name to use...

It would and it seems that I have to decide whether I want that css tiddler to be displayed nicely or whether I am allowed to actually use macros in it... right now I am still inclined to do the former, but in general, if you want to use a color from the palette you...

Use the color macro...

.myClass{
background:<<colour page-background>>;
}

But then don't assign that tiddler tagged $:/tags/Stylesheet a content type of "text/css", because TiddlyWiki won't interpret it as wiki markup but plain text insead and you will literally assign the string to your property, which won't work.

So, it would be nice, if tw5 would by default render tiddlers $:/tags/Stylesheet in a monospaced block rather than wikify the contents... or if one could easily make it so without modifying the ViewTemplate.

Best wishes, Tobias.

[Jeremy Ruston]

Hi Tobias

So, it would be nice, if tw5 would by default render tiddlers $:/tags/Stylesheet in a monospaced block rather than wikify the contents... or if one could easily make it so without modifying the ViewTemplate.

I do agree that the current stylesheet rendering is unhelpful at the moment. The same problem also occurs with HTML templates such as "$:/core/templates/static.template.html".

There would be two parts to addressing it:

* Hide the body of tiddlers tagged "$:/tags/Stylesheet". This would need to be done in "$:/core/ui/ViewTemplate/body"

* Add a new view template segment that selectively displays the parsed tiddler content as plain text

The trouble is the first part: we're in danger of embedding a lot of logic in that "$:/core/ui/ViewTemplate/body" template. I think we need a mechanism for more flexibly configuring conditions under which the default body rendering should be hidden.

Note that we could also flip this around, and instead add a new control panel tab that lists the active stylesheets in a select box, and allows them to be selected and viewed as a plain text block.

Best wishes

Jeremy

Best wishes, Tobias.

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.
For more options, visit https://groups.google.com/d/optout.

[Tobias Beer]

Hi Jeremy,

 

I think we need a mechanism for more flexibly configuring conditions under which the default body rendering should be hidden.

We could have shadows like...

• $:/config/ui/hide/ViewTemplate/body
  
• $:/config/ui/hide/ViewTemplate/tags
  
• $:/config/ui/hide/ViewTemplate/toolbar
  
• $:/config/ui/hide/PageTemplate/sidebar
• etc..

...to specify a filter that would hide the elements for matching tiddlers and then the logic in the templates to work the magic.

Or the other way around defaulting to a meaningful filter for when to show things ;)

• $:/config/ui/show/ViewTemplate/body
  
• $:/config/ui/show/ViewTemplate/tags
  
• $:/config/ui/show/ViewTemplate/toolbar
  
• $:/config/ui/show/PageTemplate/sidebar
• etc...

As for that source view, that could directly be part of the body template as it needs not be a customized thing, conditionally triggered via $:/tags/ViewTemplate.

Best wishes, Tobias.

[Stephen Kimmel]

I have always wanted the in-tiddler table of contents to jump to the appropriate heading when clicked and tough assured repeatedly that such behavior would be extremely difficult if not impossible that message never quite made it through my thick skull. Now I am extremely close to getting the behavior I want. There are still some rough edges and I secretly hope that someone, like Danielo perhaps, can help me push it over the top.

I've made a couple of key modifications since the version listed earlier in this thread.

https://groups.google.com/forum/#!searchin/Tiddlywiki/toc$20single%7Csort:date/tiddlywiki/6zBxrj4nV34/NucvoBSuscYJ

I changed the ToC items to invisible buttons and added the message so that it would write the name of the selected heading to a data tiddler.

\define regex-feature-header() (^!+.*)(?gmi)
<div class="box">

<h3 style="text-align: center;"><u>Table of Contents</u></h3>

<div class="TOC">
<ul style="list-style-type:square">
<$list filter="[all[current]match:text<regex-feature-header>]">
<li>

<$button class="tc-btn-invisible" >

{{!!title}}
<$action-setfield $tiddler="$:/sk/new-find" text={{!!title}} />
</$button>
</li>
</$list>
</ul>
</div>
<$click/>
</div>

You'll note that I added `<$click>` as well. This goes to my modification of Danielo's ~DoubleClick to edit. In my version instead of invoking the editor, I use

var lastfound=this.wiki.getTextReference('$:/sk/new-find');
     
    lastfound = lastfound.replace(/!/gm, '');

var  strFound=self.find(lastfound);
  if (!strFound) {
   strFound=self.find(lastfound,0,1);
   while (self.find(lastfound,0,1)) continue;
}

Now, a single click on the Table of Contents item writes the heading to the data tiddler and a following double click jumps to that heading within the tiddler. So to jump to the first occurrence of a heading item, you have to click three times. I would rather just double click but there is a programming step I'm missing. And if you have two different headings with the same text, it will find the first one. To find the second one, you would have to go back to the ToC and double click the entry again.

This is functional and extremely close to what I want though sub-optimal.  I would rather have a simple double click accomplish everything and I would like a simple repeat search keyboard shortcut so I could avoid having to scroll to the top.  I would appreciate it if someone could suggest how I could further modify this.

[Zhiheng Lin]

I've found a Chrome extension "Smart TOC" can do this trick without the need of an "in tiddler TOC" mechanism. 

Extension URL: https://chrome.google.com/webstore/detail/smart-toc/lifgeihcfpkmmlfjbailfpfhbahhibba

But be awared that it's not prefect when you open multiple tiddler, or your tiddler has an incomplete heading hierarchy.

On Thursday, November 20, 2014 at 9:55:05 PM UTC+8, Stephen Kimmel wrote:

I use Tiddlywiki at work. I work with a lot of documents of different types. Some are legal documents and affidavits. Others are contracts and specifications. Some are well structured while others seem to ramble pointlessly. Some are lengthy while others are very short. I need to be able to figure out quickly which document contains a particular requirement. I've found that Tiddlywiki with its search function, and especially with Danielo's context search plugin, is almost perfect for my task.Everyone I've shown my wikis to has been envious.

One key criteria in my line of work: for existing documents, I must have every word and character correct and in the right order. Most of these documents must not be edited. For example, I can't change any part of an existing contract. I can highlight portions of it but I must not change any word or word order or punctuation mark. Using a clause from one document in another is rare enough that simply copying is the obvious answer.

Consider the two alternate ways of doing things; the preferred Tiddlywiki method of breaking my documents into small pieces and my current method, the document dump.

I don't so much create tiddlers as dump documents into them. Dumping a document into a single tiddler is fast and easy. Open the word document. Copy the entire thing. Open the wiki. Create a new Tiddler. Paste the document into the tiddler. Name the tiddler to match the source document name. And I'm done. If I care to preserve the formatting, I add three quote marks at the beginning. Total time expended, perhaps a minute. If I really want to make it pretty, I can spend 10-15 minutes adding exclamation marks to mark headers or use Danielo's Keysnippet routine to convert some jumbles into neat tables.

This creates what can be a very large tiddler. The search function works as expected and rapidly identifies which document contains which phrase. It has every character and every word in exactly the right order. It accomplishes what I need to accomplish with a minimal amount of effort.

And the disadvantage? So far I haven't found one. If Tiddlywiki processes the tiddler more slowly, I haven't noticed.

By comparison, the Tiddlywiki preferred choice, lots of little tiddlers, is a good deal of work.

I've tried copying and pasting individual segments from the word document into individual tiddlers. Each smaller tiddler takes about the same amount of time to set up as my much larger single tiddler but after that I'm still not done. I still have to rebuild the original document from those individual tiddlers and I have to verify that I got all the material correctly. When that is done, I have to create a field and tagging system so that each smaller tiddler will reflect its source document and sort correctly so the table of contents will be right.

If I saw any real advantage to using a lot of little tiddlers to accomplish the same thing that can be done with one large tiddler, I might go ahead and spend the extra time. The last couple times I went through this exercise, it took me hours rather than minutes. And what did I get for my effort? As close as I can tell, nothing but older.

One thing that would make my life easier would be a table of contents that worked inside a single tiddler that was based on headers or some invisible marker. I know this has been requested more than once and now, perhaps, you can understand why I want one. A simple list of headers would be helpful. I could then use the browser's Find command to jump to the appropriate section.

[Milind]

Hi,
       I am also looking for such a plugin to port my Tiddlywiki Classic to the new Tiddlywiki. The tidtoc mentioned here http://tidtoc.tiddlyspot.com/#GettingStarted looks very good. Is there a version where the headings grouped in the TOC can act as links to the headings in the tiddler? That was how the Tiddlywiki Classic TOC used to work.

Thanks,
Milind

[Roger Ferrari]

Hello Milind, sorry to bring it up, just curious if you got that?

I am trying to have this small table of contents linking to the sections inside the tiddler.

BR,

Roger