A future enhancement I’d like to see: A “don’t violate outline hierarchy” mode. Right now, if you move a parent item, its children don’t automatically move with it unless (a) they’re selected, or (b) the parent item is collapsed. In “don’t violate outline hierarchy” mode, child items would always move with their parent, regardless of whether they’re explicitly selected or the parent is collapsed. I believe this was standard behavior with all outline-based software until the craptacular One Note came out.
This is actually one of TaskPaper’s most and intended features! Much harder for me to maintain the internal runtime model with the current behavior then outline constrained editing. The idea is that for many users traditional outlining feels restrictive. People are used to edition “plain” text 99% of the time, so structured outline behavior can create frustration.
With that said I do eventually want a separate “outline” model, though not sure when I will get to it. In the meantime I have implemented outline “move” behavior internally, and you can access it through scripts. (And then map keyboard shortcuts to those scripts) More discussion can be found:
I’ve generally believed that people who insist on turning an outlining model into a word processing model aren’t going to be very successful using it for task management, but I’ve never been very successful convincing anyone else of that. Your implementation really works pretty well for us strict outliner types as well, but when I have time I’ll try that scripting approach.
+1 for, in essence, always move children with parent. Should be the default — at almost any cost, imho.
Long, long, long, long-time outliner for pretty much all data … Ecco, InfoSelect, can’t remember, Circus Ponies Notebook, OneNote, DevonThink … keeping families together is simply standard, because it is useful. Outlining is the creation of meaningful dependencies; those dependencies should be protected.
I don’t expect to add this. For people who want shortcuts for outline linked movements, they can do that with scripts. I know it’s a few steps, but it’s possible.
One the other hand I think (it is what I originally did) adding separate documented commands for each movement command (and its outline constrained variant) just creates too much generally complexity for people getting into the app. In particular when I try to write the user guide it makes things feel pretty confusing.
The longer term solution that I would like to try is to use a separate “outline” mode that you enter with escape key. Then you use all the standard move command (and there shortcuts), but they are outline constrained in that mode. I won’t be getting to it anytime soon, but I feel it’s the best long term solution.
Much harder for me to maintain the internal runtime model with the current behavior then outline constrained editing. The idea is that for many users traditional outlining feels restrictive. People are used to edition “plain” text 99% of the time, so structured outline behavior can create frustration.
Your implementation really works pretty well for us strict outliner types as well, but when I have time I’ll try that scripting approach.