@lespea out of curiosity, which approach towards filtering do you prefer? Both are doable and pretty easy to implement for what it's worth so that isn't really too much of a concern.

A third idea I thought of randomly was kinda combining both - prune out any branches that have absolutely zero children that match the search, but keep any branches that have at least one child that matches the search and gray out all entries within the branch that don't match. This allows you to still preserve the tree structure for relevant branches, while removing any irrelevant branches.

I'm also open to any other suggestions, so feel free to let me know.

EDIT: Got a basic (very WIP, things are free to change) version of what I mean with my suggestion, so something like:

where it normally looks like:

Yeah that's something similar to what I had in mind... looks great!

Just another thought to throw out there, in windows (process hacker) you can collapse a tree entry and it will "add up" the sub entries into the parent. So it would add up all the cpu/mem usage of child processes, add it to it's own, and display that. maybe if you were navigating you could hit like space bar or something and it would collapse it? I don't think that's something that would be required just wanted to point out other successful strategies.

But honestly if you were to ship what you have in those screenshots that would meet 99% of my needs.

Great work!

Is it possible to get also the children to be shown when filtering?
In htop sometimes I'm searching for the parent process to find the child process that is stalling the parent one.
(Primary used for when something goes wrong in emacs)

Yes, that's something I'm working on adding since I also don't like the current behaviour. Also, in the future, feel free to open a new issue for a feature request like this.

Oh nice!
Do you want me to open an issue to track this feature?

@Narice filed an issue here: #668

Feel free to add to it if you want.

Oh thank you! I'll follow the linked issue then.