What's going to become of TaskPaper?

Continuing the discussion from My Use Case (maybe very edge):

UPDATE! The response below is old. The current status of TaskPaper is that version 3 is being developed and can be downloaded at http://www.taskpaper.com.

I’m not sure.

I see TaskPaper as two things. The idea and the app.

I see the idea as “finished”. I think if I try to extend it with any new syntax to do more it will only complicate things and take away TaskPaper’s primary advantage. FoldingText for Atom is the place where all new ideas will go.

I see TaskPaper the app as functioning but old and getting older. Unfortunately updating it isn’t a simple matter. It’s based on a number of outdated and removed OS X technologies (such as Objective-c garbage collection) So even a small update would require updating almost all of the code.

I’m really enjoying working on the Atom platform right now. And have fantasies of building a modern TaskPaper on it. (with the same plan that I have for FoldingText for Atom, which is that I’d also release a standalone version so installing and maintaining Atom wouldn’t be necessary).

I think someday I’ll do it, but for the foreseeable future I think FoldingText for Atom will be taking all of my time. This new modern TaskPaper wouldn’t change any of the basics that are already in the current TaskPaper release other then modernize and take advantage of the hackable and cross platform nature of Atom.


From my perspective Taskpaper would also be “finished”. I can’t think of anything I would want to add to it. Most anything would be scriptable if needed. I could easily see myself being content with using it “as is” for another 10 years (probably not the best business plan for you though). With the PlainTasks package on Sublime I can reliably use the files on Windows at work as well.

Too bad so much of the technology is now outdated. Here’s hoping it will still be running with Apple’s OS until you get time to modernize it.

When I bought TaskPaper, I actually bought several things:

  • A “get things done” solution based on plain text. This means that I can work outside TaskPaper to do things that TaskPaper fails to support in any way, such as large reorganizations of projects.

  • A solution that works seamlessly on Mac, iPad, and iPhone. So I can consult tasks or add a task everywhere on the iPhone, or can think things through on iPad or Mac.

Right now, the Mac+iOS value is lost. I bought TaskMator after the demise of TaskPaper for iOS, but things got to the point where I cannot use the iPhone to consult tasks, because TaskMator cannot navigate my main 789-line work-related file. And recently, TaskPaper on Mac started crashing on a specific file if it happens to be on Dropbox, which is the whole point.

So, here I come looking for a solution. I found Editorial for iOS, which seems overkill, but it does have a TaskPaper mode.

And I started to warm up to the idea of Folding Text (non-Atom). I believe that it would suite my needs to have a markdown file for each large project, and write a journal of the project. And mark some lines as “TODO” items, preferably in a hierarchical way. The result would be a sort of “Literate tasks”, like Knuth’s Literate Programming. And being based on Markdown, I could seamlessly integrate those into other tools, such as Pelican, which I use to publish my blogs. So I was looking forward to change.

What I found today was a complete mess. Folding Text (non-Atom) is being abandoned, even before I adopted it. Dead end.

And what about Folding Text for Atom? Well, it is not for iOS, and it is not based on plain text. And it looks suspiciously like Emacs, where you are supposed to customize key bindings. Well, I abandoned Emacs in the 1990s, and I do not wish to go back to anything similar. After all, that is one of the reasons why I use Apple computers.

From my point of view, Jesse has created an incredible solution with TaskPaper, then proceeded to throw the good parts away… because he doesn’t like the number of “#” in front of title?

I agree that Markdown sucks. It is a pity that people keep reinventing the wheel of “plain text formats”, instead of looking at mature formats like ReStructuredText or Textile. And Markdown is a growing pain as different tools implement subtly incompatible variants of Markdown. For example, GitHub does not even support description lists. The horror…

But what I absolutely do not need is another data format, because my data is more important (to me) than any tool. I understand how tool developers may think otherwise.

And I do not need Yet Another Outliner. There are plenty of those.

Sorry for the rant, Jess, but you did mess up my day. And my next few months, until I identify and settle on a working solution. The next solution will be based on plain text files.

FoldingText for Atom isn’t data format dependent and it doesn’t really add any new data formats… right now it supports:

  • ftml - This is a new file extension, but that data format is just html. I’m switching to this format so many many years down the line it will still be easy to read/write the files along with all metadata. That can’t be said for less popular plain text formats such as .taskpaper.

  • opml - This is a standard outlining format that many other apps can read/write.

  • plain text - You can copy/paste plain text formatted outlines (tab indented plus using TaskPaper’s @ style attributes.

  • I have a prototype (not really recommended yet) of import export of Markdown formatting into Atom. Also expect to add TaskPaper import/export support.

I consider all of my apps TaskPaper/FoldingText 1-2/FoldingText for Atom to be outliners. I would agree that FoldingText for Atom is more traditional, but I’m working to make it feel more like a text editor:


FTML is a new format. It is the native format of Folding Text for Atom. You can import/export to other formats, but it will be an explicit action, and these operations tend to lose data, often in subtle undetected ways.

Your tool wants “my” data in "your " FTML format. That is quite different from having “my” data in some sort of standard format readily understood by a number of different tools, across platforms. Even if Markdown is a poor standard.

Keeping your data open is a very powerful proposition. It enables you to easily leverage the strengths of any number of tools, and to compensate the limitations of each tool.

  • TaskPaper proposed a very interesting text-based open format.
  • I assume that FoldingText tried to bend Markdown into doing the same (note: I have not run FoldingText! I am working from third-party opinions on the web).
  • FoldingText for Atom is not at the same level. You need higher-level tools, and you start without any iOS support or third-party support.

If I were to craft tools to handle FTML, I would need to parse… XML? SGML? I am no longer at the level of the “perl one-liner”. Note: I have worked with XML-based text formats, so I have some feeling for the effort required. For my simple stuff, I would prefer very simple text-based formats.

This is not to say that your way forward with Atom is wrong. However, I wonder if you realize the value of what you are leaving behind, or even the core values that made TaskPaper ressonate with my needs.

However, I have seen other users looking forward to use Atom, and I wish you the best of luck.

I do not regret using TaskPaper at all. In fact, that success is why moving on (to presumedly worse alternatives) is so painful. Gosh, I probably sound like the little boy that dropped his lollipop in the mud!

I’m not a geek who wants to play with new toys. I too consider FT for Atom as a big step back and will use the original Foldingtext until it breaks apart. It’s beyond me, why a developer abandons smart, proven, flexible solutions (Taskpaper, Foldingtext) in favor of restricted stuff.

Jessy, I bought all of your apps, because everything you made was a little stroke of genius, simple but powerful. Until now I don’t find anything of that spirit in this app.

This isn’t quite true.

FoldingText for Atom also reads/writes opml files directly. If you have FoldingText for Atom installed and drag and drop a opml file onto Atom it will open as a FoldingText outline and when you save changes it will save as opml.

I hope to handle taskpaper and markdown files in a similar fashion in the future. Though unlike opml these will be somewhat lossy depending on how I decide to balance readability of the plain text versions with encoding of all runtime attributes.

I’m not sure that I follow.

I assume your data is currently in TaskPaper format? That is a very nice and quick syntax for simple task lists. And it has the nice benefit that it’s easily read/write in any text editor. But it’s certainly not a very rigorous standard. And while it can be read/write in any text editor correctly processing it isn’t easy to do correctly.

FTML on the other hand is just a strict subset of HTML. That means it IS HTML and can be displayed in any browser and read by any HTML parser. I’m not saying is necessarily right for your case, but I’m pretty sure that FTML (or OPML) is a much better format for long term data stability and easier processing outside the use of any of my apps.

Or if you are looking for a common format I think OPML is read/write by many more tools then is the current taskpaper format.

Thanks for using my other apps. I guess the one thing that I would say is that FoldingText for Atom isn’t done yet. It’s definitely in a “new toy” stage. It’s not for sale yet and hasn’t hit 1.0. Still a ways to go. I would check back once it’s released and maybe you’ll like it better.

The plain-text format of TaskPaper files is, for me, its greatest advantage. The format will remain useful, even if you move along.

Thank you very much for creating the TaskPaper format.

I understand this feeling. Taskpaper is unique in it’s simplicity of entry, presentation of information through visual formatting, powerful query language, and basic portability. It feels odd that something seemingly so simple won’t continue down that path.

I have no idea what Taskpaper will be like once it’s updated, but I can discuss my experiences with FT for Atom so far.

I’m finding the more I use FT for Atom the promising it seems. Even in it’s current state I’m able to sit down with it and map out and manage small projects much easier than I am with FT2. The switch from a plain text file with Markdown tags to an HTML format has required a few adjustments and it does leave behind the aesthetic simplicity of plain text. However I think eventually there will be more than can be done with the HTML format than just plain text. And I’m not worried about sustainability. HTML isn’t going away any time soon

The issue I always ran into with using .taskpaper files in other programs is I would lose the functionality or presentation layer. My needs were usually swapping between OS X and Windows. Using Atom will take care of that problem for me, I hope.

Remember as well that FTA isn’t in a finished state. I’m not sure what we call this. An Open Beta? An open invitation scrum meeting? Regardless, what the final version looks like and what tools/extensions/scripts become available are unknowns.

I’m still using Taskpaper regularly. If your biggest concern is sustainability of the plain text format, have you looked at SublimeText 3 using the Plaintasks package? I find it a bit clunky to use but all the functionality is there and more. I use it for working with .taskpaper files on Windows. Once I learned the keyboard commands it’s been very solid sharing files with Taskpaper.

Thank you for nailing down the feeling. I really want to maintain that simplicity.

I understand that the current direction of FoldingText for Atom may serve other users better, especially Mac-Windows compatibility.

Thanks for the tip. I will start with TextWrangler and taskpaper-bbedit, because I have a long tradition of using BBEdit and now TextWrangler. Right now I intend to keep using TaskPaper while building a library of alternatives.

Once upon a time (ie, a few months ago) Windows was a minor need for me. Dropbox and the plain text format was enough to make minor edits at work using Windows, even without any specific tool. Windows is currently not an issue, although that may change again in the future.

What is not a minor need at this point (for me) is compatibility with iPhone and iPad. Having my task list (literally) at hand in iPhone and iPad is a distinct advantage which is lost with the new FTML format.

I understand that the developer has “bet the farm” in FoldingText for Atom, and that the bet cannot be undone. I see how others can see me as the “Velho do Restelo”, the old men at the Portuguese “Lusíadas” that complains in 1497 Lisbon as Vasco da Gama starts the voyage to reach India by sea.

However, the TaskPaper format ticks my core value of data for the ages in a way that the new FTML format does not. Because there is nothing more portable than plain text.

I know I’m late to this thread…

Try TaskMator again. I had the same problem (large main file) but managed to get Amit’s attention (developer) and he’s recently introduced a fix. I tend to move between TaskMator and Editorial for managing my ft/taskpaper files on iOS. Note: Editorial’s next update will also bring some nice features for Taskpaper users…

Personally, I plan to use FT2 until FTA is mature enough to make the jump with minimal impact on my current workflow, or until the benefits that FTA offers or so compelling that any other issues pale by comparison. The only things that really bug me with the most recent (bleeding edge) release of FT2 are the expiration notice and the occasional “disappearing text on reboot” bug— neither of which are deal breakers. While I love FT2 for everything it currently is, I’m excited about the possible future for FTA, I just know that it’s not ready for me to adopt, and probably won’t be for some time yet.

Re: OPML— CarbonFin Outliner was useful when I last played with it (a while back, now) and offers Dropbox sync of OPML files. Might be useful for us to list compatible iOS apps that could support our mobile needs? And it might not hurt (if Jesse doesn’t have his own strategic plan for developing compatible iOS apps) to communicate with amenable developers so that they’re aware of features a community of future FTA(TP) users might benefit from? Taskpaper, as a format has third party developer support— I’m presuming it’ll be a while before anyone develops anything with FTA(TP) in mind…

Just my two euro-cents.

The main attraction of TaskPaper and FoldingText has always been that they use plain text files.

It makes it so easy to manipulate the data in ways the app never conceived of, such as via scripts or apps like Drafts or LaunchCenter Pro (both for iOS).

I can edit the files very easily with any old text editor, as the format is quite simple.

This was—for me at least—always their main strength vs dedicated, database-based todo apps like OmniFocus or Things.

Moving to a markup language throws most of that advantage in the bin without gaining the advantages that an integrated, database-based todo app has.

What am I suppose to do with the files on my phone? Grub around in Coda and bash out a load of tags, just to add a simple task?

What’s the TODO file going to look like in my GitHub repos if it’s full of HTML tags?

I appreciate the advantages of a markup-type language—I wrote my own TaskPaper parser that first converts TP docs to XML so I can use xpath queries on them—but as long as there isn’t broad support for the format, especially on mobile, it is—for me at least—essentially useless. Am I really supposed to bash out a bunch of HTML tags just to add a task or to cobble together my own app using Pythonista or Editorial?

I also really don’t want to have to use Atom. It’s a terrible application. Massively bloated and a battery killer because it’s basically a web browser masquerading as an editor. It’s literally a case of “let’s take the slowest platform we can find and build an editor on that”. The desktop equivalent of an iOS app wrapping a WebView.

I don’t use Atom for coding because there are proper editors available, and a 100+MB, slow as molasses FoldingText is a terrible idea.

Please reconsider.

If you have to go with a markup language, then just use OPML. It is, at least, widely supported, and users hopefully wouldn’t need to use a slow, bloated, fat pig of an app like Atom to work with it.

Thanks for your feedback. Few quick thoughts…

  1. Atom is to much for many people and more important (for me) I expect it’s very difficult to sell any Atom based product.

  2. With that said, I really like the development workflow, expandability, and cross platform reach of Atom.

With those things in mind here is the state of things.

Since almost exactly a year ago I worked on my next text engine called among other things (FoldingText 3.0, Birch, and now FoldingText for Atom… will have a new name again pretty soon separating it from FoldingText). The current result of that work is FoldingText for Atom… which runs within Atom.

I’ve going through a public dev cycle of that code (posting releases to these forums) and my takeaway was that the model layer was working well, but people wanted (more like a text editor). That’s what I’m working on now.

Instead of creating my own editing UI in HTML I’m mapping my tree model to a text buffer… much like how FoldingText 2.0 and TaskPaper currently work, but with some enhancements and not tied to any particular editor for display.

I started out mapping outlines to Atom text views to get the basics working. But over the last weeks I’ve taken my model layer and embedded it in a native Cocoa app and display the model in a native NSTextView.

Here’s a very in progress screenshot:

It’s a single outline displayed in a Cocoa app in a NSTextView. Behind the scenes is the same Javascript outline model that I’ve been using in Atom, just now it’s displayed in a native app. In the second window the outline is displayed after hoisting “Header”. Notice that in the second view there is no tab indentation before One, Two, Three, so it’s a “real” hoist… something that TaskPaper and FoldingText 2.0 could never do.

Not working yet, but folding and filtering should be pretty strait forward to implement I think. I expect the next dev version that I release will be this native app after a few more weeks of work.

They will be out of sync for a while but the goal is to have an Atom version for hackers and power users who want all the cool stuff that the atom platform provides. And then a Cocoa version for people who just need a simple native app.

As far as file formats/apps. TaskPaper 3 will use the same file format and same syntax highlighting behavior as TaskPaper 2. I expect TaskPaper 3 will be the first app that I release based on this work. Once that’s out then I’ll get back to my pure outlining app (more like current FoldingText for Atom), except still based on text buffer UI as described above, which will use the more feature rich file format and features that it provides.


Good to have this update, Jesse. I’m currently largely happy with FT2, but looking forward to future developments.

I’ve got a couple of questions, which you may or may not have answers for yet, as plans shift a bit.

  1. Will Taskpaper have an Atom option as well or just a native app?
  2. Will the two same search syntax of tags and values work in both? If I recall the search in Atom works pretty well with the ftml format…but i haven’t tried with values since I don’t think that’s in the UI yet?
  3. Any thoughts yet on iOS compatibility. Preview mode in Editorial works OK for reading FTML files, but not for working with, at least not in the base configuration.


Yes that’s the goal, though probably won’t be as polished as native version.

The model layer (which includes the search) should be exactly the same.

I expect TaskPaper to continue using the existing plain text format, so editorial or Taskmator or any other app that can read task paper files should still work. I know it’s all rather confusing. But there are three things that I’m talking about:

  1. The underlying technology for representing an outline in memory, querying it, loading it, etc.

  2. The outliner app, currently called FoldingText for Atom, which is built on that underlying technology, and uses .ftml.

  3. TaskPaper 3.0, which will also be built on the same underlying technology, but won’t use all the same features that the outliner app will use. For example TaskPaper’s UI will continue to be syntax highlighted (type @tag for a tag) and save as a plain text format.

I expect TaskPaper 3.0 to be different in lots of ways, but the fundamentals should stay the same… syntax highlighted plain text.

I’ve changed my mind and explantation of how these things all relate quite a few times, so I can certainly understand the confusion. I think best bet is to just wait for the TaskPaper beta and see what it actually turns out to be and go from there.

I have always loved the simplicity of Taskpaper and really have only two requests for the new Taskapaper. Keep the ability for developers to add their own themes (maybe simplify using CSS), and have the ability to “fold text.”

The folding text part is what is really needed to take Taskpaper to the next level. Otherwise it an awesome program.

@CaptainCowpie Text folding will be in TaskPaper 3, actually working on it this very second.

CSS style themes are less likely. TaskPaper 3 is being implemented (view part anyway) in native NSTextView. This is good because it will give the native editing experience and save me a ton of work trying to recreate that experience. But it means that I won’t be using CSS/DOM in a web view for display, so it won’t be as theme-able as FoldingText.

Eventually I do hope to add some sort of theme system (somewhat like TaskPaper 2), but I haven’t started to work on that or think about it in much detail yet. I just know that full CSS/DOM flexibly won’t be possible.

Sorry to hear about the loss of themes in the short-term, but having the ability to fold text will more than make up for it. I have quite a few long documents that would benefit from that feature.

Editorial on iOS has folding along with a Taskpaper mode, and it has proven to be extremely useful.