Minor Bug in TOC: Showing > on empty sublist

#1

I’ve noticed what looks like a (minor) bug when using exclude with <<toc-selective-expandable ... >> If there are tiddlers with tags matching a node in the tree, but all of them are excluded by the filter, we still show the right arrow. Clicking it, gives you the down arrow, but no children.

You can download the following and drag it onto an empty wiki or any other one and load “Demo”:

TOC_Bug.json (1.8 KB)

It includes

<<toc-selective-expandable 'Root' exclude:"[!tag[MyTag]]">>

Note that while there is a tiddler tagged Qux (Wug), that tiddler does not have the tag MyTag. Foo > Qux has no children in this hierarchy. Hency, it should not have the icon; it should look more like “Grault”, “Garply”, and “Waldo” in this tree.

It doesn’t expand to show anything, so this is fairly minor, but it definitely seems like a bug.

> Foo
  > Qux
  ^---------------------- Doesn't belong
> Bar
  > Corge
     Grault
> Baz
    Garply
    Waldo

While I could probably figure it out, someone who knows the TOC code would be able to do it many times more quickly. Should I simply raise an issue on GitHub?

Or am I missing something? Is there a reason this behavior is intended?

#2

The TOC macro definitions are found here: $:/core/macros/toc.

In the definitions for toc-linked-selective-expandable-body() and toc-unlinked-selective-expandable-body(), the following filter is used to detect when the current tiddler has “children” (i.e., tiddlers tagged with the current tiddler title) in order to display the rightarrow or downarrow.

<$list filter="[all[current]tagging[]$sort$limit[1]]" ...

Note that the filter doesn’t take into account any tiddlers that are to be excluded from the TOC output. To correct this, add -[subfilter<__exclude__>] to each instance of the filter, like this:

<$list filter="[all[current]tagging[]$sort$limit[1]] -[subfilter<__exclude__>]" ...

enjoy,
-e

1 Like
#3

Sure, it sounds so simple when you say it! :grinning_face_with_smiling_eyes:

This fixes the issue for me, and seems to have no negative consequences. I think this is a core fix. I can submit a PR if you’re otherwise engaged.

– Scott

#4

Yea, you should do so. Eric prefers to create detailed, high quality descriptions how to solve problems. But it seems he stays away from GitHub.

#5

I’ve submitted a pull request for this. Thank you @EricShulman for the help, and @pmario for the explanation of Eric’s preference!