X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/51ec7e4655f891de167e8e112e7599505ef4438a..c4cb6e3c346199929b42ab0c352e33b36f55b72e:/doc/plugins/toc/discussion.mdwn?ds=sidebyside

diff --git a/doc/plugins/toc/discussion.mdwn b/doc/plugins/toc/discussion.mdwn
index 3d4c2b149..11c874fcb 100644
--- a/doc/plugins/toc/discussion.mdwn
+++ b/doc/plugins/toc/discussion.mdwn
@@ -1 +1,31 @@
-If you are using the sidebar plugin and have a header in the sidebar it shows up in the table of contents.  I can see why this happens but it surprised me and wasn't the desired effect in my specific situation. -- [[AdamShand]]
\ No newline at end of file
+If you are using the sidebar plugin and have a header in the sidebar it shows up in the table of contents.  I can see why this happens but it surprised me and wasn't the desired effect in my specific situation. -- [[AdamShand]]
+
+A related side effect: If you use any sort of headers in the page
+template (such as placing the page title in an `<h1>`), the toc plugin
+picks it up.  I suppose it parses the entire page rather than just the
+rendered content. --[[JasonBlevins]]
+
+Why doesn't the TOC appear in the edit page preview?  It only appears when the page is finally rendered.  This makes it somewhat difficult to organize headings, saving & re-editing all the time.  My user page currently has a toc to play with: --[[sabr]]
+
+> Fixed. --[[Joey]]
+
+Just ran into a side effect of `\[[!toc]]` being a NOP in pages
+which are inlined: pages with `\[[!template id=note text="[[!toc]]"]]`
+wound up having the note rendered in feeds as "Use this template
+to insert a note into a page". Worked around this by making a local
+copy of the template and removing its `<TMPL_UNLESS text>...</TMPL_UNLESS>`
+section. Besides needing to generate guaranteed-unique anchor names,
+are there other reasons this directive couldn't be made to work on
+inlined pages?  --[[schmonz]]
+
+> Workaround: `\[[!template id=note text=" [[!toc]]"]]`
+> (with whitespace) should work, because then Perl will consider
+> the string to be a true value.
+>
+> Longer-term, my branch on [[bugs/template_creation_error]]
+> aims to fix this sort of thing. --[[smcv]]
+
+>> Workaround seems not to. Maybe whitespace is getting trimmed
+>> along the way and it stays falsish. Interested in your branch;
+>> sorry I can't offer precise feedback right now, but it looks sane
+>> at a glance. --[[schmonz]]