TaskPaper 3.0 Preview (154)

  • No longer include “@type” in search autocomplete list.

  • Removed Group and Dupicate items keyboard shortcuts. Not sure they are right ones, better to just leave blank and let users decide I think.

  • The Item > Move > Branch Up/Down commands are less constrained. They still move “branches” of items instead of just selected items, but the movements are more fine grained.

  • When reading a file tabs are no longer used to determine the indentation level for empty lines. Instead empty lines are always inserted at the same level of the next non-empty line.

Download TaskPaper 3 Preview

Thanks very much for removing constraints on Move Branch.

Can i make one more suggestion? When I Move Branch past a higher level, the branch promotes and demotes. I think a branch should keep its level. For example, starting with:

Heading1:
- Subhead1
- Subhead2
– Subsubhead1
Heading2:
- Subhead3
– Subsubhead2

If I Move Branch Subhead3/Subsubhead2 above Heading 2, it promotes one level so that Subhead3 is the same level as Headings 1 and 2. I then have to Move Branch Right

Heading1:
- Subhead1
- Subhead2
– Subsubhead1
Subhead3
- Subsubhead2
Heading2:

I would rather that a branch maintain its level when I Move Branch Subhead3 up, producing the following.

Heading1:
- Subhead1
- Subhead2
– Subsubhead1
- Subhead3
– Subsubhead2
Heading2:

I’ll reply in this topic: Move Branch Smoothness

Hi Jesse,

First of all thanks for releasing the preview of TaskPaper 3. I’m one of the folks that have been long waiting to see what you’ve been working on.

Before moving to TP3 (I’ve been using probably all the previous releases of TP and FoldingText), I have a couple of questions:

  1. TP3 won’t support any sort of Markdown
  2. TP3 supports links
  3. Will TP3 support custom themes?
  4. Will TP3 support any flavor of scripting?

Thanks!

(as a side note, in the preferences, there’s a small typo “archviing”).

Correct.

Yes, it should do that now.

Yes, it should before 3.0 final, but it doesn’t currently.

Yes, it will at minimal support FoldingText style scripting. That is a small apple events interface through which you can pass JavaScript that will be executed against TaskPaper’s internal scripting model (like FoldingText, TaskPaper is mostly a JavaScript application).

I also have the goal of creating a backward compatibility TaskPaper 2 scripting interface. But I started that last week and gave up because implementing AppleScript support is a big pain and nothing ever works as I expect. I imagine I’ll try again later I guess.

If TP3 does not support Markdown, it would be helpful if there was another way to bold text other than making it a project. Perhaps starting the line with “>”? This would also coincide with the iOS app Upword Notes which bolds entries leading with “>”.
Thanks!

I think if I do decide to add syntax for bolding text I’ll use markdown syntax. Just not sure if I’ll be doing that for version 3.0 or not.

1 Like

Would still like the ability to bold text. I use Taskpaper for writing outlines and bolding text would be huge. Also need completed tasks grayed out!

I might add bolding going forward, but it won’t be in the 3.0 release.

You can grey out done tasks with this custom theme:

@doneColor: lightgray;

item[data-done] {
  color: @doneColor;
  > run[display] {
    text-strikethrough-color: @doneColor;
  }
  > run[link^="button"] {
    color: @doneColor;
  }
  > run[tag] {
    color: @doneColor;
  }
}

Thank you. I do not know how to paste this into user.less.

The file that you need to paste in actually changed to theme.less. Instructions for editing themes can be found here: http://guide.taskpaper.com/creating_themes.html

I’d like to +1/upvote on minimal inline MD formatting.

Adding **bold** and _italic_ (or *italic*, via preferences) would allow seamless transitions between TP3 and FT2 as well as other MD editors, and makes perfect sense to me from a pure TP usage standpoint.

Menu item (or preference ?) to show/hide syntaxe might be a good idea as well (I prefer it to be shown).

On the other hand, I would rather suggest to avoid possible conflicting formatting like leading >.

Cheers.