[SOLVED] Paste to project not working [it is working]

I am trying to get this Drafts action to work:


by following the support document reference


Unfortunately, if I specify a project name, this line is created as a task instead of (what I expect) that any indented task is created within the specified project. For example I have this draft:

Test project:
    - Do stuff
    - Do more stuff

This is created in my Inbox as a first level task of ‘Test project’ with 2 sub tasks. My expectation was that I would get 2 first level tasks created in the project, or have 2 tasks in the Inbox, with the project as their attribute.

Is this way of specifying projects supported? Am I doing something wrong?

Any help is appreciated.

That is correct. If you don’t specify optional parameter


the result is an action group (in the inbox) with two child tasks.

For example, to create a top level project, the syntax would be:


I hope this helps. Tell me if you have more doubts.

Thanks for pointing this out. I had already figured this out, too. The thing is: the taskpaper specs on the support page refer to project items conforming to the official specs. But pasting a line ending in : and a newline does not do anything.

So I’m still curious if and how lines with Project names are supported when pasting.

You’re welcome.

What do you mean by that? If you use the syntax I posted, it creates a top level project. Perhaps I’m missing something…Could you give more details?

To create a task in an existing project, you could use the add command.



P.S.: There isn’t a @project tag in TaskPaper syntax, if that’s what you were asking.

specifically mentions

A project is a line that isn’t a task and ends with a colon (‘:’), or a colon (‘:\n’) followed by a newline. Tags can exist after the colon, but if any non-tag text is present, then it won’t be recognized as a project.

My expectation is, that if I paste a draft with this syntax, al tasks that are in this draft’s project will get this project in OF.

This is default TP behavior and allows one to add tasks to different projects from one draft.

This lets you create one single task whereas the paste function allows for a batch/hierarchy.

Well, actually there is. By design, completed items can be moved to an Archive: section in the file and get that tag with the original project’s name. Perhaps this tag could/should be supported by OF, too.

It’s going to create a new project in the location specified by the target optional parameter. If it’s not provided, it will paste it in the inbox.
This syntax allow for the creation of new projects/action groups/tasks.

add command creates one task at a time. You probably know this, but you could use a Workflow Repeat action to create many tasks (ie. in a specific project) with this command. Of course, it would create a flat list, not allowing hierarchy.

I think there is a reason to not support @project tag. If a user tries to paste TP text with a this tag, what do you expect to happen?

Pasting TP text into OF allows for creation of projects/action groups/tasks via URL Schemes, currently.

I hope this clarifies a bit.

So, if the target is a folder, it will create a new project there?

I would expect that specific task to be added to the project concerned if it already exists or the Inbox if the project does not yet exist. Does this make sense?

It does. I will do some more testing.

That’s right.

E.g. To create a “Test project” in a Someday folder

TP Text

Test project:
    - Task 1



I think the problem would be if a user tries to paste this TP text.

Test project:
    - Task 1 @project(Shopping)
    - Task 2 @project(Work)

I cannot think of a predictable result in this case. “Test project” would be created with no children tasks.

Tell me if you need anything else.

1 Like

I know. For arguments sake, you could make 2 design decisions here.

  1. Ignore the project tag if a Project line is available
  2. If a project tag exists ignore the Project line.

In the latter case you could of course end up with empty newly created projects.

I completely understand why the developers would never support the project tag, just to stay away from this error prone complexity.