While #19 has already been closed by #47, the convenience of the current filter mechanism is still very limited. In short, in some situations, users might want to hide only specific contexts, whereas, in other situations, they would want to hide all their callees, too. The current approach only supports the first use case.

Reconsidering different scenarios for filters:

• composite sends (#allMorphsDo:)
• #exampleShutDown (simple do:)
• hide exceptions ((1 to: 3) do: [:x | x squared] displayingProgress: [:x | x asWords].) or execute around methods (#becomeActiveDuring:, see: Project current world doOneCycleNow) from stack
• flatten (temporarily or by-design) inadequate hierarchies from source code

With the exception of the last (so far mainly fictive) scenario, a better filter mechanism would cut away contexts from the stack from the first filtered-away context (e.g., Morph>>#allMorphsDo:) up to (exclusively) the first block context whose home context was called outside of the filter. In other words, the filters should only be applied to the method context of stackframes ("through filters"). See Context>>#cut: for a comparable mechanism.

However, there is another (still much more elaborated) limitation of this approach: If the "evaluable" passed into e.g. a composite send is not a block, the focus on home contexts from above is too specific. E.g., for (1 to: 10) sorted: #asWords ascending or (aTdbTrace childrenForFilter: aTdbContextFilter), the filters would also hide Integer>>#asWords or TDBContextFilter>>#value:. To encounter this problem, some kind of tracking mechanism to determine the origin of an object would be required (see #74).