Getting to this late, but it is intentional behavior.
I know it doesn’t fit into an easy logic, but I think the key point is that text editing commands are the exception.
At model (API) level TaskPaper is an outliner. When you move an item with the API the items children move along with it. From the model’s (both programming and people’s mental model of how there outline is structured) point if view I think moving children with the parent makes the most sense. And so most of TaskPaper works this way, archive done, drag and drop items, filtering items, etc.
But… as great as the outline model is for many people the actual editing process feels “heavy”, “constrained” compared to editing plain text. I know because a while back I implemented a preview version of my app that worked like a traditional outliner and gots lots of “NO WAY” type feedback right away.
So for this reason TaskPaper’s common text editing move commands are not outline constrained. Instead they work just like a simple plain text editor model that’s embedded into the muscle memory of many computer users.
To confuse things a bit further… there is a special case. If an item has hidden descendants they will be moved along with the item when using TaskPaper’s move (up, down, left, right) commands. For example if you collapse an item and then indent it, you’ll notice that it’s children are also indented.
Again this exception doesn’t have a simple logic, but I still think it’s “right”. The way that I think about it is that when an item has hidden descendants it:
- Is indicated by filling the items handle dot red. Those hidden items visually become part of that item.
- So it makes sense to move those children along with the item since they’ve become visually part of it.