Hi!
When I’m moving a task with a child node (e.g. a note) it works fine when using the Move To Project menu option (both the task and the note are moved). But when I’m selecting Move [Right|Left|Up|Down] the note is not being moved along with the item - only when I collapse the task (when the dot is red). Is this expected behavior or am I missing something (using TaskPaper 3.6 build 283)
Thanks!
In this case, it is the expected behavior. To make things easier, just remember the command to collapse the item Cmd 9 and then move it to where you would like it.
Why is this expected behavior? Shouldn’t all the “Move” commands show similar behavior towards the items they’re moving? I would also be happy with a setting “Move with children” or something similar 
This is a tension between making TaskPaper feel good as a text editor vrs making it feel good as an outliner.
The problem with always moving child items when you move the parent is its nice for the 90% of the time when it’s what you want (if you want an outliner type UI). But it doesn’t feel like a text editor (and that’s what many TaskPaper users want). And even in outliner tools that property can get you into hard situations where need to start adding other commands like Promote and Demote to get out of.
The “move” command logic isn’t entirely consistent, but I think it feels the most correct to me given the current goals. For text editing commands I want TaskPaper to be like a text editor. But for everything else I want it to be an outliner.
Long term I have an idea for a separate “structure” editing mode where all commands would act like an outliner, but for now that’s just a long term idea.
Thanks again for the detailed explanation. I’m surely more in the outliner ‘camp’ than text editor but I can understand why some people would want a different option. It’s confusing a bit because I’d say “Move” commands are typically outliner commands and so should behave as the “Move to project” option. But that’s just me ofcourse 
What would be a nice solution is if there’d be a menu option “Move (with children) Up” etc. Or otherwise I’d think that it wouldn’t be too hard to script something right?
I had these alternative commands in menu items early on, but it starts getting confusing trying to explain the difference between the two sets of commands. It means we have twice as many “Move” commands in the menus and it all starts to look very complex. So I took out the “Move Branch” items and just focus on the default text editor move commands right now.
I think the best long term solution is a separate “structure” mode … so you’ll use the same existing “Move” commands, but in structure mode it will always work like an outliner. Structure mode would be indicated by a different selection style that always moves items as in an outliner. But as I’ve said before, that’s a long term idea.
Long story… but short of it is that outliner style move commands are implemented in the editor right now, just not exposed in the UI. They haven’t been tested much recently, but I “think” it should work to call them from your script like this:
function MoveBranchesUpTaskPaperContextScript(editor, options) {
return editor.moveBranchesUp()
}
Application("TaskPaper").documents[0].evaluate({
script: MoveBranchesUpTaskPaperContextScript.toString()
})
The other moves would be “Down”, “Left”, and “Right”.
@jessegrosjean is there any documentation on the methods of the editor object? I’m looking for something to make more things work like an oultiner, such as a KillBranch method / script that would remove all node and all children (and not only when collapsed). My current workaround is using Keyboard Maestro to first collapse and then delete.
Sorry Jesse - I should have made it more clear. The Taskpaper documentation is really great and extensive (as is also this forum). I thought I might have overlooked some documentation (or possibly it’s because the methods only exist in 3.6) such as moveBranchesUp() - are those methods also specified somewhere?
Ahh, no moveBranchesUp isn’t documented anywhere because I don’t consider it public API. I sometimes mention private API here in the forums that might quickly solve a problem for someone, but only API that’s documented here is public.
