I’m writing in relation to an OmniFocus issue, as they recently added support for exporting/importing Taskpaper-formatted lists in the iOS app.
Here’s the relevant post: Implementation Details for OmniFocus 2.14 Automation - OmniFocus for iOS - The Omni Group User Forums
Here’s a quote from that post (emphasis mine):
As you can see, one issue with this format is that TaskPaper doesn’t have any mechanism for escaping arbitrary content, so this representation can be lossy. For example, a task name that includes the text @flagged will see that text disappear from its name and the task will end up being flagged. And you can’t begin a note with a -. (To prevent mishap, on export we substitute any leading - characters in notes with en-dash – characters.)
I’d like to know if it’s feasible for the Taskpaper format to allow arbitrary character escaping?
I don’t think so, at least not in the way that you suggest… someone else please correct me if you think I’m wrong.
The issue is that TaskPaper is both a serialization file format AND a runtime syntax highlighting format. It’s possible to add escapes to serialization formats, but I don’t know if it makes sense for the runtime syntax highlighting part.
For example I think you are saying that you’d like a “note” to start with dash space? It makes sense to do this kind of thing in an app like OmniFocus that doesn’t parse the note text at runtime to determine it’s type. But in TaskPaper I don’t know what should happen if it read in this file:
\- my note that starts with dash space
I think the intent would be to display (but have it’s type as a note):
- my note that starts with dash space
But in TaskPaper that wouldn’t make sense… the fact that it’s a project/task/note is determined by parsing the visible text at runtime after every keystroke. So even if it was somehow make a note to start with… it would immediately never to a task after the first edit.
In this situation I think it makes sense for Omni to add there own layer of escapes when loading and saving. For example that might encode notes that start with "- " as "- " and then decode them when reading files. But the TaskPaper format itself doesn’t have a place to do that.
Ah, I see the conflict. I agree with you, there’s no good way for Taskpaper to handle this on its own (nor should it need to).
I agree a good/consistent solution is for Omni to backslash-escape the characters themselves, since their format isn’t a 1-1 GUI implementation of Taskpaper. TaskPaper would have no issues parsing the extra backslashes; you’d just see them rendered as-is, since Taskpaper is effectively ignoring them/treating them as a plain note.
I also think the (power) users of this feature of OmniFocus would have no issues understanding an escape character. If they’re editing the raw Taskpaper output from OmniFocus, they’re likely comfortable with the limits of syntax/formatting already.