Jerud I agree that the highlighting isn’t a definitive indication of “matchingness”.
Jeff It might be good if it could be set per-filter, or even within a filter.
That sounds complicated. Per-pane seemed like a big enough ask.
What I mean by “per-filter” is that a control could be on the filter pop-up pane, with all the buttons. There could be another button called “strict ‘and’” or something, that you could check or uncheck at will, depending what you’re trying to accomplish with the filter at that moment. Maybe people need one kind of filtering for their to-do list, and another kind for their journal. The setting could be “sticky”, and remain on or off for each pane until you change it, so in that sense it would be per-pane. It just makes sense to me that it would be in that filter popup, rather than in some other part of a pane’s settings like the View menu. I wish the “collapse matches” setting was there too, it would be more convenient than in the global settings.
You seem to follow a “top-down” approach: the parent is the match (first matching item encountered on the way down the tree) and its children are then being included inappropriately (without inheriting anything).
Well, first that doesn’t change the fact that your example isn’t a valid instance of where some non-excluded descendants of a matching item are not shown, since the item doesn’t match - so I still disagree with the “clarification” about it. Secondly, I’m not saying the children of a matching item are included “inappropriately”. That’s the way it’s designed. It’s useful in many or even most cases. The “collapse matches” setting helps me to reduce the often overly-large amount of results when filtering my notes. A “strict” matching option might help a lot too. I don’t necessarily want them every time, but maybe as an option.
Yes, I do visualize the filtering as starting at the root, and walking along the branches until it finds the first item where all the terms are satisfied, and then simply displaying all the descendants deeper than that. Well, it still does have to analyse them in case they match an exclude term. There are various well-known algorithms for tree traversal, but in general they start at the root and move to the leaves. For example, the standard find or dir command for searching the computer’s file directory hierarchy. I guess it’s not impossible to start at the leaf nodes and work up, but that’s not normally how it’s done. I’ve also never heard of a system where each node keeps its own copy of all the properties of its ancestors. I think that would be terribly inefficient. There’s nothing in Jay’s description of his algorithm to indicate that either of those unusual and unlikely things are happening. I don’t see any advantage to picturing that they are. Jay does say that “it’s extremely complex with how it deals with hierarchy”. So I don’t presume to know exactly how it works internally. But I have yet to see any example that contradicts the simple principle that all the non-excluded ancestors and descendants of a matching item are always shown, even if they don’t match, nor any reason that I need to stop thinking about it in that way.
I don’t think an ancestor that’s only shown because it “has to be” should count as a “match”. It is certainly a shown item, but calling it a match doesn’t seem accurate or helpful.
Right, and I’m saying the same thing about the descendants that don’t explicitly match the filter, but are shown anyway, not because they “have to be”, but just because Legend is designed to do that: “It is certainly a shown item, but calling it a match doesn’t seem accurate or helpful.” When it is called a match, and is included in the count in the status bar, see all the awkwardness and inconsistencies involved in trying to talk about hierarchically-matching “and” filters with “collapse matches” on, in And in filter with outline view shows wrong items.
The discussion of “strict” matching for “and” has mostly been related to the principle that Legend’s “and” filters run across the whole hierarchy, so e.g. a filter for filter this will match item “this” with ancestor “filter”. The principle that all descendants of a matched item will be displayed is a separate principle, at least in my mind. So if we have “strict” non-hierarchical matching, and an item matches all terms itself (or there’s only one term) that wouldn’t necessarily apply to the display of its descendants, which, along with the item’s ancestors, could still all get displayed. I mean, it could be made that way, if you have “strict” filtering, that a matching item’s descendants also have to explicitly match, or be individually hidden (as opposed to collapsed). But it could still be the other way too, where they all get shown. I don’t know what would be best.
