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 find nothing.
moo.do supports search for A B, where A and B are fulfilled at different levels.
Search for A_1 A_2 ā¦ A_n should match all nodes that have all the words somewhere between the node itself and the root of the document, and which contains at least one of the terms.
"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. "
yes.
this is a must !
I often find myself wanting to search for two terms (foo bar), when there is a node with ābarā that has a parent with āfooā.
Actually, Iām often not sure if (foo bar) will work or not, since āfooā could also be in the sought node, but I think it should not matter if it is in the node itself, or in the ācontextā (parent nodes).
Without a feature like this it takes a lot more effort to find the right items.
Itās feasible, but potentially very costly to check all levels of parent. If only the direct parent needs to be checked, itās much easier and the results will appear much faster.
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!
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.
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.
