New filtering system

Had inadvertently replied in the Beta Updates thread so deleted and reposted to this thread instead:

Not sure what’s going on, but I’m getting weird behavior with the dashed border indicators and the filters. After setting a filter, I’m getting dashed borders on a whole bunch of items that are not to be hidden and then not getting it on an item that is changed to not match filter. And then that item never disappears until I make some other changes. Can’t really figure it out.

I think I prefer the old way (faded, automatic but delayed disappearing after losing focus) but I’ll reserve final judgment until I see the dashed border thing working properly. While I didn’t mind it, I recognize the conflict with completed items, so not sure what the answer is. Could consider changing deleted items to strikethru, though that’s not visually as easy to work with as faded text.

Maybe instead of the dashed border, try faded text but with a color, like light red?

Jay Going to also chime in again on my favorite topic of auto-expanding/collapsing, also mention by @Jerud:

It should at least be an option, if not the default behavior, that auto-expansion occurs when any filter is changed, not just the text filter, whether the filter is set by buttons or text (in simple or advanced mode).

As Jerud metioned, matched items should be auto-expanded to show their children solely due to the children matching based on inheritance. The children should have to meet at least some portion of the filter criteria. That said, I think inheriting properties for filtering is too complicated and confusing to be the default behavior. I haven’t seen that with other major outliners, but I could be wrong. Maybe make it an option also?

Related to this, as you know by now as I have been begging for this for years , I also feel strongly that matched items should be auto-collapsed (or that should be an option too) if no children match the filter criteria on their own (this is the way other major outliners work). I approximate this by always keeping a pane with the outline fully recursively collapsed, but that shouldn’t be necessary.

I like having a different visual effect from fading. The dashes are okay though I might prefer red like andrew says.

In filtered Panes I’m seeing dashes within the results as I apply the filter, not when I make changes to the items. It seems like the dashes are between two items that are non-consecutive in the (unfiltered) outline. I like this, though I’m not sure if it’s intentional.

Auto-expanding to show filter results is happening now but is too aggressive. If a top-level Parent matches, it gets fully, recursively expanded even if none of the children match. I understand that technically all those children do match and are thus included in Pane contents because of inheritance…but this isn’t a helpful behavior.

I am trying really hard to just learn and understand inheritance without asking for different features or behaviors…but in so many cases it’s counterintuitive or just plain unhelpful for what I’m trying to do. Surely it’s not so weird to just want to see items that exactly-match a filter? I keep coming back to the idea that having explicit control over whether inheritance is used to display filter results would solve this. For this specific case, at the very least, I think legend should understand the difference between self-matching and inheritance-matching and only auto-expand as far as needed to show self-matches.

For the record: I’m not against inheritance, or even using inheritance by default. I use it in plenty of situations, since it essentially lets you assign tags (and other properites) “in bulk.”

But there are just as many situations where I want exact matches. Especially for filters that employ negation or booleans, it can be very hard to achieve predictable results. Simple example: PARENT = plain and its CHILD = Task. If I filter to hide Tasks, I see just the Parent. The child doesn’t inherit the mutually-contradictory non-task-ness of its Parent. So inheritance apparently is overriden by the child’s property. I particularly hate this behavior because the parent is shown without the ‘expander’ caret. So it is either hard (if bold parents is ON) – or impossible – to tell that it’s a Parent at all. I can’t figure out any reason to actually want this outcome.

How does this work with priorities, where the different options have a ‘hierarchy’? Example:
Priorities (multiple, ranked states): If PARENT = pri1 and its CHILD = pri2. Child gets filtered as if it is both pri1 and pri2 at the same time. You can’t, actually, do anything to hide either the parent or the child whether you use pri1, pri2, -pri1, or -pri2 filters.

Jerud Are you talking about the date filter icon that used to be under “contains”? I don’t see it after I just updated a couple of minutes ago (Update 1641415995942), but I swear it was there for a short while when I updated this morning (Update 1641351385129). I was playing around with it thinking “Oh, this is what Jerud was asking for!”

Did @Jay do something by mistake in the latest update to remove the “has:date” (or whatever it’s exact wording is) icon in the basic search?

Really appreciate the auto-expand on all filters, however it is doing so for most but not all matching items. Can’t figure out why but will look for a pattern to try to reproduce.

webalstrom I’ve checked for it after each update pushed to me, although I might have got a double-update at one point. I haven’t seen it reappear yet. Perhaps it’s due to the shift from “HAS:date” to “DATE:any”. They’re functionally identical, just organized/phrased differently…

Thanks for all this work!

Jay I’m fine with “collapse matches of filters” as a general setting. Being unable to differentiate a collapsed parent with no matching children from a leaf item is still problematic (regardless of this change). What do you think about showing the ‘ >’ but when user expands the parent they see a message under it: “none of these child items match the current filter.”

The date:any button is back for me. Will have to test the other bugs in a day or so; I need to work away from the computer for a while.

Jay I think global setting makes sense.

The auto-expand/collapse is working nicely with text matches. It doesn’t seem to be reliably expanding or collapsing for some other filters like star button, priority (in simple or advanced mode). Will have to experiment more with it later.

I think this update introduced a new bug.
Repro:

1. Open Note editor
2. Type some text
3. Use shift+arrow to select some of it
4. Overtype or delete the text
5. Exit Note editor
6. Try to arrow-up/down

If you exit the editor via shift+enter, up/down causes the pane to scroll
If you exit the editor via “X” button, up/down do nothing
Expected behavior: up/down moves cursor up/down

BUG: I’m seeing completes shown in hide-completes Panes. They are children of a mirror which is, itself, not complete. Have not observed this with non-mirror items

At least, I think it’s a mirror. It has an always-visible tally box, but the item text draws as a [[Link and appears inside [[braces]] in the breadcrumbs. It’s an old item but I’m pretty sure it was a mirror that ‘degraded’ to a link, as they do.

BUG (?); Can’t specify sort-order in the Pane Configuration dialog for “group-by” Panes. The up/down sort-order arrow is not shown. The arrows for the next column over (Item sort-order) are still available.
Obviously not filter-related, but seems to have broken due to the most recent round of updates.

Or am I imagining it? I swear this used to be there.

My previous post on this thread brings up a separate issue… one of the benefits of the old filter panel is that it never obscured the results. With this new bigger panel and a very narrow pane (which all of my panes are), it does. Mostly an issue when using it as a filtered search, where you are looking for an item that appears at the top of the pane. That’s why I would be pressing ESC before typing the text.

One thought is to have a filter icon button (such as a funnel icon) to toggle the filter panel rather than showing it when clicking in the filter text input. Then you could also use it to hide the filter panel, and you could type in the filter text input without having to close the panel first.

Another idea is to shrink the filter panel so it doesn’t obscure the first item(s) in a narrow pane.

Pressing ESC before typing is a reasonable workaround as far as entering filter text (would be nice to have an x to close the filter panel as well). Just wondering if anyone else has a preference for how this should work.

BUG: It seems that the text filter is not matching on items with a note, unless the note itself matches the text filter.