No collapsed bullet point in search results for parent node that has collapsed child nodes

🐛Bugs
#1

Steps to reproduce

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.

#2

I was unable to reproduce your bug:

After searching #tag1, both parent and child nodes displayed, with no collapsed indented nodes.

#3

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.

#4

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:

766×214 14.2 KB

Use tags, instead, to directly jump to items that contain those tags - which can only be zoomed in rather than expanded.

1 Like
#5

I see where you’re coming from.

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.