Linking Taskpaper files

Hi Jesse,

Would it be possible to link between documents, in the same way that evernote can link to other notes?

It could be useful in creating a daily dashboard document with a task to review another sheet, clicking the link in that task, which would then open the other sheet for review.

Not a mandatory, but could help with multiple file setups.

This would be great. Something similar to nvALT note linking…one could even maybe link to file URL’s, allowing file attachments of a sort.

The next release will recognize “file://” urls for doing these sorts of things.

1 Like

More of a nice to have, but consider supporting the relative link format similar to Plaintasks for Sublime. It’s the only thing going on Windows.

Format is pretty simple but powerful and more closely represents standard file paths across platforms:

./another filename/

It also supports this through MD like anchors to connect an external file to specific text in the task.
There’s other tricks (like linking to sections, text and lines in an external file) but those are the basic file links.

A relative file path is also preferred when syncing files between machines and between Dropbox users (shared task lists).

1 Like

I’ll consider this, but first want to get file:// urls in there, they seems like a more standard approach. It’s true that file:// urls are always absolute, but for the case of TaskPaper 3 I’m going to interrupt them relative to the TaskPaper document that contains them.

Until Jesse has some time to support file:// urls, you could look into hacking together something akin to what I have here (very outdate though).

Better yet, check out Brett Terpstra’s port.

The current TaskPaper preview should support file:// URLs. The problem with file URLs is they are always supposed to be absolute which I think we don’t want in most cases for TaskPaper files.

Because of this I’m interpreting them as always relative (consider the TaskPaper file in which they are embedded as in root folder of file system that they refer to). But of course that’s problematic too, because currently there’s no way to link to an absolute path on your file system.

I think I probably need change this and make file:// URLs absolute to the current file system. That makes them less useful, but more predictable. It also leaves the problem of how to link to files from TaskPaper with a relative path.

PlainTasks has a special syntax for this, and that’s one solution. But I’d like to avoid specialized syntax if possible. That got me thinking about how web pages use href for relative paths. Has anyone ever hard of href being used as a URL scheme? Unless there’s some good reason not to… I’m thinking we could solve relative paths in TaskPaper like this:

  • href:my/relative/path.png


Relative paths are certainly better for this sort of thing. I have not seen any application URL scheme that used href. Could you at least go for a hybrid of href:.\my\relative\path.png

I’m being selfish because I still need it to work when I use the file on Windows with PlainTasks

I might be able to hack that… though i’d prefer to stick to what would go into a standard href attribute and I don’t think backslash paths are correct for that. But it looks like PlainTasks will handle unix style paths with forward slashes. So would this work:


It still won’t be recognized in TaskPaper right now because my matcher for finding URL protocols won’t find one that starts with a . right now. But if this seams reasonable I can adjust that I think.

1 Like

I could live with this implementation. Will surely make it much easier to link to external files rather than using my previous extended info script :wink:

niiice, file:// works great. Would be nicer to have it as links (href style) I guess, but I can totally live with this, and it makes it apparent that these are external links :smile:

I’ve just started implementing this… but have come to the conclusion that href is to loaded a term. It’s used for all sorts of URL links, not just file system paths. Instead I think I’m going to follow @macdrifter’s original advice and follow Plaintasks lead with a few less constraints (until I guess I learn why the constrains where there in the first place). Here’s the regex that I’m using right now and it seems to work well in my files:

/(?:^|\s)(\.?\/(?:\\\s|[^\0 ])+)/gi

It basically says:

  1. Anything that starts with / or ./ is a path.
  2. The path continues until a space is encountered.
  3. If your path does have a space use \ to escape it.

So with that in mind paths look pretty much how they look in the terminal. We get support for both relative and absolute paths. When you drag and drop a path onto TaskPaper it will automatically create a link.

Plaintasks seems to also require that the path has a trailing /. I guess that’s to avoid false positives? Or Make it easier to have paths with spaces? But it comes at the expense of having the path not really look like a real path. So for now I’m going to go with my more relaxed recognizer, but I’ll consider changing it in the future if it turns out to give to many false positives.

Also I’ll keep support for file:/// paths, but I’m changing them back to always being absolute. So if you want a relative path you’ll (in next release) need to start with ./ syntax.

1 Like

The ending slash is not required in Plaintasks if you use one of the more explicit notations like Markdown file links.


Here’s other examples that work in PlainTasks:

[support doc](/SupportDocuments/Work/"{>>ChemReg<<}")

The bit in quotes is nice. It links directly to the first text match of the linked file. So in this case matches to a line where I have {>>ChemReg<<} in the document.

1 Like

I want to upvote / +1 / like / whatever_way_to_rise_it_to_the_top that quotes trick form @macdrifter.
Inspired by the method developed by Christian Tietze, I use unique timestamp-based IDs to identify documents or bookmark a specific section in them.
Being able to point the link directly to one of those ID would certainly be a key feature.

1 Like

Thanks, I have I’ve added an item for this in my feature requests list. I can’t say when/if I’ll implant something, but its recorded and reviewed when I’m trying to figure out what’s next. My concern is that I don’t want to add to many inside magic tricks too soon. I already really need to just spend a lot of time documenting the current stuff before I keep adding :).

I do think that you could get 90% of the way there with an AppleScript.

Here’s a start, it uses two bits of private API that could change in the future, though I think that’s unlikely. Those bits are bodyHighlightedAttributedString and the knowledge that bodyHighlightedAttributedString can have a link attribute that might start with path:. If you didn’t want to use private API you could just parse out your own links given the current item and item offset.

var TaskPaper = Application('TaskPaper')

function TPContextGetCurrentPath(editor, options) {
  var selection = editor.selection
  var item = selection.startItem
  var offset = selection.startOffset
  var attributedString = item.bodyHighlightedAttributedString
  var attributes = attributedString.getAttributesAtIndex(offset)
  var link = attributes["link"]
  if (link.indexOf("path:") == 0) {
    return link.substr(5)
  } else {
    return ""

var path = TaskPaper.documents[0].evaluate({
  script: TPContextGetCurrentPath.toString()

// If path conforms to some syntax (maybe ends with "characters")
// Strip that part off path.
// Open path in TaskPaper
// Set characters contained in the ""s as current search filter.
1 Like