It’s by “implementation” … meaning it was much simpler to implement this way (I just reuse the standard text view implementation)) and it does make some design sense. If the implementation was the same difficulty I’m not sure how I would design it. And in fact (in the next text editor component that I’m designing) the implementation is pretty much the same difficultly either way.
So nows a good time to lobby to change it!
I think there is some value to the current design. It enables you to do find/replaces that wouldn’t be possible otherwise (i.e. find and replace only @done items, or some other filter search). While also not disallowing any find/replaces…since you could always just expand everything.
With that said I can also see the benefits of making find work on hidden items too.
As I’ve said before I’m also in the process of building in an optional library file browser. That brings up more search questions eventually. Might not get to it in first iteration, but eventually it would make sense to have options for:
- String search current document
- Item path filter current document
- String search all documents
- Item path filter search all documents
And any variations in-between. I’m quite a ways from building it all, but any thoughts/suggestions are welcome.