The whole project one will be gone, which is understandable since you deleted its heading. But project two will be gone as well, and you never selected any of it! With no undo…
Thanks again for the clear report and sorry for the unexpected behavior.
There’s certainly room for improvement, but this is actually how I expect it should work right now. (also for me undo seems to work fine in this situation, please let me know if you are sure there’s an undo bug). But maybe we can find a better way for a future release.
I think there are two absolute approaches to editing in a view with hidden gaps:
TaskPaper 2’s approach was that only visible items are affected. This seems reasonable (why I started with it I guess) … but is actually problematic. The problem is when you delete a project Because even when you delete a project it’s hidden tasks are left orphaned in place.
TaskPaper 3’s approach is to work like a programmer’s text editor (sublime or something similar). All text (hidden or not) enclosed by the selection is selected. This model seems simplest, and works well enought in those editors, but they have more visible fold indicators, and I think there folds are all hierarchical… so they don’t deal with filtered sibling items.
I guess there is a third hybrid option. Something along the lines of:
Work like TaskPaper 3 if a visible ancestor is selected.
Work like TaskPaper 2 if no visible ancestor is selected.
Anyway… I guess I’d like hear what you and other’s think. I know I don’t want TaskPaper 2 model. I think maybe with better indicators TaskPaper 3’s current model could work… though this hybrid model at the moment seems pretty nice.
In my example the selection doesn’t actually go over invisible lines. It’s only one project. But the usual way of selecting several lines places the right boundary at the beginning of the next line, which because of the filter is a long way away. It’s too easy to make that mistake.
I understand what you mean, but in my implementation is actually does cross over those lines. The selection is actually ending at position 0 of “To Fold, Focus …” So the filtered projects between are enclosed by it.
Anyway I am liking the hybrid approach above the more that I think about it. And it would solve this particular case pretty well I think. Unless someone comes up with a better idea, or finds a major fault, I think I’m likely to at least try implementing it for the next release.
In Tobias’ example, what I’d expect is this: selecting the whole filtered content of the first project and deleting should remove the whole first project, including the hidden tasks, but not the second project that’s hidden between the ones visible in the filtered view.
Trying to abstract this idea: the selection should extend to the inner content of the projects in the filtered view but not to its hidden siblings.
Please try out the latest 3.2 preview (198) and see if that behavior works well for you. The new behavior should be that hidden items that overlap the selection are only included in cut/copy if those items have a visible ancestor.
That shouldn’t be the case unless you are running into some sort of bug. I just tried and undo continued to work even after canceling the filter. One issue that you might be running into, I just noticed that undo only works when the text view has focus, maybe after canceling the filter the focus was in the sidebar or search field and that’s why it didn’t seem to work?