This seems similar to a problem that browser developers have to address to implement descendent selectors (https://www.w3.org/TR/2008/REC-CSS2-20080411/selector.html#descendant-selectors). Maybe there are similar approaches that would work for Dynalist.
Do you mean having different syntax for children, descendants, and grandchildren?
I was just thinking about the performance issues raised in your post above, and noting that browsers or other software products that support CSS selectors have to deal with the performance issues associated w/ descendants that may be some arbitrary number of levels below the parent node. I personally have no idea how they do this so my post is probably not that helpful!
1 Like
I see, thanks for the input anyway! Thatās definitely an interesting idea, having syntax to express what you need without having Dynalist assuming what you want.
Also CSS doesnāt prevent you from writing expensive selectors, itās just that you need to bear that cost yourself. Same with Dynalist, the search happens in your browser/app and not our server, so the search is too slow, hopefully the user will consider editing it.
We should probably add a warning for the potentially slow queries though.
Thatās a good point
1 Like
I think I agree with @Bjarke_Ebert. It would be useful to have a sort of AND search that allows the words not to be in a single node but also finds them spread over several nodes but a single ābranchā.
But Iām not sure I understand the discussion. @Erica, it sounds like you are talking about zooming into a node and performing a search. Right now, it only finds hits from this node and its children. Are you suggesting to include the parent into this search? Sort of, as if we zoomed into the parent instead of the node itself?
As an experienced software engineer I would not worry too much about performance of this tree-aware search semantics.
For indexing, just pretend every ancestor is part of the node text. As long as the tree is not very deeply nested, this should not cause problems.
Heck, you could even do normal search for the most rare search term, then filter this search result using linear walkthrough with the more advanced semantics.
Thereās no zooming involved. You could start from the root of the document or even do a search across all documents.
For example, current you can search for all items that contains āappleā in a document. If this feature were implemented, youāll be able to search for items that contain āappleā who ALSO have a parent item that contains āfruitā. The search result set is a subset of the former case, if that makes sense.
But I understand what you mean as well ā and I believe this discussion is not about where you search, but HOW you search. You still search under the current zoomed in item, that is not changed. Itās about adding a new way to limit results.
2 Likes
Thanks for the clarification, @Erica.
You definitely have my vote for such a AND search possibility that doesnāt require the terms to be on the same node but in the same branch.
There is even another thread for such a functionality: Search Function: Greatest Common Parent. (AND + OR)
1 Like
This would be a fantastic feature! I would use it daily.
1 Like
Update: added āparent:ā search operator. Cheers!
3 Likes
Brilliant feature, Erica. Any plans to allow the user to use the search operator for more than one level of parent/child?
Weāre thinking of either using an option to enable using the āparent:ā operator for all levels of parents, or adding another operator (e.g. āancestor:ā) to explicitly do that.
Because searching in more levels will give more results, Iām not sure that everyone wants that.
3 Likes
Glad to hear youāre thinking about expanding this! I suggest going with the āancestorā keyword, because they are separate use cases. For example, I use parent:Waiting to easily find the items immediately under āWaitingā nodes. On the other hand I think I would would use -ancestor:#comment to exclude entire sections of the document, e.g. for printing.
Yes I think Iād want these separate as well - having only āancestorā would remove some uses of the current āparentā search (by polluting it with irrelevant results) which would be a shame
Edit: Would be lovely to have both though 
But surely the amount of results in this type of search will be far less than the amount of results in a search without any qualifier?
And if we take the problem from another perspective :
Searching in the search.
I mean : you do your first search. Then in the search results, you can narrow your research with another researchā¦ and then again :
search thisā¦
then thisā¦
then thisā¦
ā¦
1 Like
no need to type # please
inherit the tag
and the tagged list becomes a bookmark
Example:
I have a list of jobs
Each job requires materials
Materials come from different sources
I would like to have a list item in each job list called ā#materialsā
ie job1/#materials
under #materials I would like to have another tag called
#amazon
so now I find
job1/#materials/amazon/item1, item2, etc
combined with
job2/#materials/amazon/item3, item4, etc
and when i get to amazon I can just go to one location and see the combined lists =four items
but when i am at the job I can drop requisitions into the silo in each job
they are aggregated when needed
=>you know, like a database
so the children inherit the tag in the list
because i cant be typing #whatever each time in the list
I just list them under /#materials/#amazon
and the tagged list becomes a bookmark
right now you would have to type #tag at each item
if you put #amazon and then make a list, it shows naked and then is in a search result screen with limited operators
and some materials could be sourced from different suppliers
so you would drop them in #materials and then sort later ie
ebay, amazon whatever
but job materials aggregate under one inheritable tag bookmark
Hi Paul,
Iām not sure I fully understand your use case, but it sounds like one where the parent and ancestor operators might help. If this were your document:
ā¦then you could find all the amazon items by searching parent:#amazon:
ā¦and you could find all materials by searching for ancestor:#materials:
ā¦is this something like what youāre trying to do?
1 Like