Child / sibling selectors

[jacoscaz]

Hello Dynalist!

I think there are quite a few use cases that could be addressed via support of child / sibling selectors, such as the > combinator available in CSS.

My use cases include:

• filtering entries tagged #todo within journal-style YYYY > MM > DD tree
• filtering subtasks w/ a different assignee than the main task

How hard would this be?

[Erica]

A bit hard and could potentially be taxing on search performance if you have lots of items.

I see it’s useful though, since other feature requests have been posted about this. Not exact duplicates, but pointing to the same direction:

Find search terms in parent nodes as well

I suggest an improved semantics of AND search (i.e. the default when there are multiple search terms) Rationale: As this is a tree-based document system, often words in a parent node are not repeated in child nodes, since the child already lives in a context. But when searching, this context is not taken into account to find child nodes. Example: A B C D B C When searching for B, I find all Bs in the document, which might be way too many to handle. When searching for A B, I f…

Children Inherit Parent Tags

Can each child/sub-item automatically inherit the tags associated with the parent (at least for search purposes)? That would make a huge difference using tags and searching across the board.

[jacoscaz]

Yes, I understand how search could slow down things quite a bit. Perhaps some kind of “advanced search mode” could be activated when operators such as > are detected within the search string?

[Craig_Oliver]

Perhaps we could introduce specific selectors that change a search to apply to ancestors.

For example, we currently have has:color to find anything that has a color (thanks guys!). Perhaps we could use parent:has:color to find nodes where the parent has a color, and ancestor:has:color to find nodes where any ancestor has a color.

So maybe prefixing any search with parent: or ancestor: would change the search to look up the tree.

[Erica]

@Craig_Oliver

So maybe prefixing any search with parent: or ancestor: would change the search to look up the tree.

So only search operators like has:color work after parent:?

What if you want to search for an item whose item contains two words: apple tree? If you write parent:apple tree it will be parsed as "look for items that contain “tree” and whose parent contains “apple”.

[Craig_Oliver]

@Erica

What if you want to search for an item whose item contains two words: apple tree? If you write parent:apple tree it will be parsed as "look for items that contain “tree” and whose parent contains “apple”.

I was thinking that the parent: modifier applies only to the term that it’s attached to. If you want to search for multiple aspects of the parent, you would specify it for each term it applies to.

For example:

• To search for items containing apple or tree, search for apple tree.
• To search for items whose parent contains apple and tree, search for parent:apple parent:tree.
• To search for items containing tree and whose parent contains apple, as you note above, search for parent:apple tree.

This would allow us to search very precisely for items, e.g. #task ancestor:#work would find tasks within work projects, but not home projects.

[Francisco_Barros]

@Craig_Oliver

To search for items whose parent contains apple and tree, search for parent:apple parent:tree.

Another option is parent:“apple tree”.

[Erica]

@Francisco_Barros

Another option is parent:“apple tree”.

Yeah I was thinking of the same thing.

@Craig_Oliver: I see how your solution works, it’s somewhat tedious if you want to search for “a pretty long phrase I mean pretty long” in the parent, as you need to repeat the parent: part quite a few times.

The issue with quotations as proposed by @Francisco_Barros is that it’s hard to distinguish if you’re searching for exact substring or not. In normal syntax quotations represent requiring exact matches, but here it’s a little ambiguous what’s to be achieved by using the quotations.