Copy and paste the following into Dynalist (so you get one node per line and have two child lines under the top line):
Level 1 Indent #tag1
Level 2 Indent #tag1
Level 2 Indent #tag2
Then click on #tag1 to conduct a search of that tag.
Expected result
The parent line “Level 1 Indent #tag1” would have a collapsed bullet point because even though the search results display the child line “Level 2 Indent #tag1,” the parent line is still hiding/collapsing the child line “Level 2 Indent #tag2.”
Actual result
The parent line “Level 1 Indent #tag1” displays the small, uncollapsed bullet point, making it unclear that there is still another child node beneath it that does not match the search results.
Environment
Windows 10, current Desktop app.
Additional comments
I’m not sure if this is a bug or the intended behavior, but I think it is a risky thing because you could run a search and be misled into believing that there are no other child nodes beneath a given parent node when in fact there are additional child nodes that simply didn’t match the search. There is nothing to lose by adding the collapsed bullet point in such a case.
Your video actually perfectly reproduces the bug that I am referring to. My point is that after you have clicked on #tag1, in my opinion the bullet point for the node “Level1 Indent #tag1” should be displayed as a COLLAPSED bullet point (i.e., the bigger one), NOT as a small/uncollapsed bullet point. The reason is because there is in fact the “Level 2 Indent #tag2” node indented beneath it that is in fact collapsed, even if you can still see the “Level 2 Indent #tag1” node after conducting the search. Does that make sense?
In other words, the only thing that I consider to be a bug is the appearance of the bullet point of the parent node after the search is conducted.
I see where you’re coming from. The ambiguous nodes after searching tags not displaying their indented contents makes navigating tags difficult.
However: Jumping to items using tags is meant to be a direct route to things.
Once jumped to the tagged item - while you won’t see their children nodes right away - you can still zoom in and view anything nested inside them by clicking the Zoom in function:
While this does seem like an inconvenience, the Ctrl+F search function (or the Magnifying glass on the upper right-hand corner of your document) does display expandable children nodes:
So rather than relying on tags to view the full contents of a node, use Ctrl+F to type part of the tag out:
But I wanted to mention that if you change the content of the first (parent) node to be “tag1 #tag1” in the example above and then just search “tag1,” the bullet point of the matched parent node still isn’t collapsed. The only time the bullet point displays as collapsed in search results is when every single child node beneath it doesn’t match the search query.
I think this is really unfortunate. It means that whenever I conduct a search, I have to expand or zoom in to in to every single parent node (even if one or more of its child nodes matches the search) to make sure the parent node isn’t hiding more non-searched-for child nodes beneath it that still might be relevant to my search, as opposed to to just glancing at the bullet point to determine this. This is incredibly time consuming and it could be solved by simply adding a collapsed bullet point to any node that has both a non-searched-for child node and a searched-for child node beneath it.
This got me to thinking, so here’s a little CSS code one could mess around with to develop some custom results.
Try this out in your custom CSS…
/* Child Content Bullet Indicator in Search Results Page after clicking a tag
This allows to see if listed results are parents or not
Note: Seems you only need to address the first level in the results in any code you work on. */
/* regular search /expandable */
.DocumentTools.is-searching ~ .Document-rootNode .Node.is-currentRoot .Node-children .Node-outer .Node .Node-self.is-parent .Node-bullet:before,
/* flat search /not expandable but you see if its got children */
.search-ui-document-results .flat-search-result .Node-outer .Node .Node-self.is-parent .node-line.Node-bullet:before,
/* show all dosuments search /not expandable but you see if its got children */
.search-ui-document-results .Node-outer .Node .Node-children .Node-outer .Node .Node-self.is-parent .node-line.Node-bullet:before {
content: "\e90c";
}
This issue is very similar (the same as?) an issue I brought up a few months ago here. I’m not familiar enough with CSS to implement HTHawks’ solution though I’d love to not have this problem!
