WriteRoom progress and how it effects TaskPaper

I’ve been working a lot on WriteRoom 4 ideas for the past week and a half. Here are some notes on what I’m doing and answers to some questions that I’ve had:

Why WriteRoom?

WriteRoom started as a unique and simple app. It’s recently languished and the concept’s been duplicated. WriteRoom’s “Distraction free writing” tagline now describes a whole category of software. For this reason I’ve had a number of comments from people wishing I would just continue working on TaskPaper because it’s more unique. The thought is that any new version of WriteRoom will just be another entry in the “Distraction free writing” category.

I understand the thinking, but I see lots of room for improvement and unexplored territory in the writing app category. My overarching goal as a software developer is to build better tools for thinking with text. TaskPaper is great, but it’s really meant as a planning/todo list. I really want to work on a more formal writing tool and have a number of ideas that will fit well into a writing app, but not a todo list app.

This isn’t a new goal, FoldingText was my first attempt at this. And I know many people really like it (and I’m very happy Mutahhir continues to work on it) … but for me it missed the mark in the end. For me it reached to far and became too complex. With WriteRoom my goal is just to create better place to think and write, not the “plain text productivity” goal from FoldingText.

What am I working on right now?

So far I’m just experimenting, but my focus is to improving the core text editing experience. (Note that improvements here also transfer over to TaskPaper). In particular I’m working really hard on performance, which is tricky considering the underlying JavaScript outline document model that I’m working with. (Again, WriteRoom will have same model and scripting API as current TaskPaper).

The good news is that I’ve had some successful experiments and “think” I’ll be able make some dramatic improvements to memory, speed, and editor features. My goal is to scroll "like butter!!! :slight_smile: " through 100,000 lines. Resize that window with zero choppiness. Etc. To my knowledge this type of performance isn’t possible in existing OS X apps that support multiple fonts and OS X typography. Some programmer’s text editor with a single font can do it, but a single font is a simpler implementation. Paste that much text into TextEdit and things quickly go bad.

Why should you care? Nobody makes documents that big anyway? Because I think all of this optimization will show up in much smaller documents. All the little lags that you probably don’t even notice, I think you will notice once they are gone.

How will this effect TaskPaper’s development?

I certainly don’t see TaskPaper as “done”, but In the midterm TaskPaper releases will slow down. WriteRoom work will take my creative time. I expect to make TaskPaper bug fixes, but am unlikely to add any big new features.

But remember I’m building WriteRoom on the same codebase and it uses the same underlying data model as TaskPaper. This means that once WriteRoom 4 is out I should fairly quickly be able to make a major new TaskPaper release with that takes advantage of all the work that I’ve done for WriteRoom. Starting with a much better text editor assuming I can get that part implemented.


Thanks for the update!

While I don’t know if I’ll use WriteRoom directly, and since I generally feel that TaskPaper 3.0 is stable for my needs, I have no personal concerns about this negatively impacting TaskPaper as an app with a healthy lifespan.

I do appreciate it you being forthright about it and being proactive in gathering user feedback and working to address potential concerns. I feel it shows you care about your users a lot.

1 Like

i do!

1 Like

Me too!

1 Like

I think you’re being too modest, didn’t you invent distraction-free text editors? I use a combination of FoldingText and Ulysses (and the great nvAlt), and of course TaskPaper, but I’m looking forward to whatever you think should come next for text.

1 Like

I used to use WriteRoom all the time (a medium sized article every week). One of the things that I liked best about it was the ability to change the look somewhat. I especially liked that one could add a little whitespace (extra leading) between paragraphs. That idea is rarely (never?) seen in current distraction-free editors. I hope that you will keep some ability to control formatting features like this (or really, especially this).

Before too much progress is done with WriteRoom, would we get the Library view in TaskPaper? I am looking forward to WriteRoom. I have honestly bought too many word processors, but I am looking forward to see what you will come up with.

Sorry I don’t think so. Integrating the library view with TaskPaper is going to require to much thought/design/re-design with TaskPaper’s overall UI to do it quickly.

Okay. No problem. Looking forward to see what happens with WriteRoom.

Could it support TextBundle format?

I’d love a text editor that keeps the tag and outlining features of TaskPaper (and which make Workflowy such a great tool to develop ideas with) but without being wedded to the idea of task management. Is this along the lines of what you’re thinking of?

I suppose I’m in a minority but the plain text foundation is a requirement for me. I realise it makes a lot of things more difficult. But it does mean I can keep .md and .taskpaper files in the same folders and easily search them with a variety of common tools.

Certainly possible, but to early to tell at this point. That feature is in the back of my mind now though.

I expect some outlining features, but my goal is “place to write”, not necessarily outliner. Right now my thinking is that the UI won’t have folding/filtering, but will allow you to focus on a heading and navigate your document by heading. I don’t have plans for tags at this point.

For both of these features I could change my mind going forward, but I wouldn’t expect then in the first preview (still a few months out I would guess)

I very much expect the file format to be plain text, likely Markdown. What I meant is that my goal was limited to writing, not supporting lots of different modes such as FoldingText’s calculator, timer, etc.

1 Like

Don’t want to be negative, but I’ll just say it: I loved WriteRoom 2.x, and hated WriteRoom 3. So anything you coudl do to recapture the simple elegance of WriteRoom 2 would be much appreciated.

If you have some specific details of things you liked in 2.x vrs things you don’t like in 3.x that will help.

My big focus for WriteRoom 4 is:

  1. Performance, I want it to be able to handle novel size documents and stay really fast, something that I think most NSTextView based editors don’t do. This is requiring that I build a custom text editing view, which is taking the vast majority of my effort to this point.

  2. Library View, a sidebar allowing you to browse your library (a folder and subfolders containing plain text files) of documents. This view can easily be opened/closed with a keyboard shortcut.

On top of those core features I have quite a few other ideas, but not sure if they will make it into initial release, so I’m not taking about them yet.

1 Like

Wasn’t sure if I should put this here or over in the start-of-development announcement thread, but here are the things I would be most excited about for WriteRoom 4, in order of excitement level:

  1. Performance.
  2. Performance.
  3. Performance.
    • Glad to see that’s a top priority. I’ve tried a lot of markdown editors, and so many of them don’t render text natively, which makes working with/manipulating my large dissertation writing files a pain.
  4. A library view on the left side.
    • Again, super glad to see this is a focus. For me, the ideal library view would be a cross between iA Writer and notational velocity: allow for expandable folders, with a searchbar that searches file contents/highlights occurrences. Also, I’d love to see the ‘file open’ behavior of Sublime Text/Atom–so selecting a file displays its content, and it pops into a new tab if you edit it or press enter/double-click. Panes might be cool, but this feature probably wouldn’t be used by many users/would take away from the simplicity.
  5. Folding!
    • The single most important reason I use FoldingText over other editors.
  6. Taskpaper-style tags/filtering
  7. Slack-like slash commands for triggering actions/extensions and inserting predefined text snippets.
  8. A limited, well-thought-out set of markdown syntax helpers.
    • I have in mind something like Caret’s table-syntax helper. Maybe the ‘average’ user would benefit from having some visible UI element that, at the very least, shows some syntax-helper options in a dropdown. But I, myself, would want these hidden away, triggerable by something like the above-mentioned slash commands.
  9. A file templating system.
    • I don’t know how may people would use this, but I currently use a set of boilerplate .md files that I copy to start any new paper/handout/letter/notes/etc. It would be cool if the editor supported this kind of workflow, as it would be really awesome if different file types could, say, load different script extensions or be automatically pre-filled with information in a dynamic way (e.g. a ‘monthly report’ document is automatically filled with Headers for each day of the current month.)
  10. An javascript extensions API.
  11. Default syntax highlighting for YAML metadata out-of-the-box.

A last general comment: after a lot of experimenting/fiddling, I’ve come around to the idea that I need different things when planning vs. writing. And so I do almost all of my work in a split-screen full-screen window, with Taskpaper on the left (for notes/ideas/plans/tasks), and FoldingText on the right for any and all ‘content’ that I produce and put out into the world. This seems to be the way you’re thinking about it too? In any case, I’d be very glad if you keep the products distinct and ignore users who want you to Taskpaper-ify WriteRoom.