Default support for wiki-link to PDFs

Ideas
1

Use case: directly link to PDFs in the space via wikilink syntax, without the help of any plugin. This would not be so hard, since if a link ends with .pdf it will be automatically picked up by the PDF viewer of the browser. We just have to tell the wikilink parser: insert .fs/ before any PDF link.

Currently I do something like

function noteLink(noteName)
    local base = js.window.location.origin -- get the basename of url
    local notePath = base.."/.fs/typeset-notes/"..noteName.."/"..noteName..".pdf"
    -- manually insert the /.fs/ part
    return "["..noteName..".pdf]("..notePath..")"
end

function refLink(refName)
    local base = js.window.location.origin
    local refPath = base.."/.fs/Refs/"..refName..".pdf"
    return "["..refName..".pdf]("..refPath..")"
end

so that I can both access PDFs from my server and enjoy quick loading of PDFs when running in localhost.

I'm aware of the wonderful Silverbullet-PDF viewer, but in my honest opinion supporting PDF links (we already have custom wikilink support for images anyway) could make the onboarding experience feel nicer.

1 Like
2

This could be as easy as

function pdfLink(path) -- Use this with the full path, including file extension
    local base = js.window.location.origin
    local url = base.."/.fs/"..path
    local name = path:match("([^/]+)$")
    return "["..name.."]("..url..")"
end
3

Does this not work out of the box? If no document editor is installed SB should fall back to opening that document in a new tab through the fs link.

4

Yes it does get forwarded, but it seems to trigger a popup which might get blocked (Safari on mobile seems to block all popups by default...). In the cases where the popup is allowed, an error "fail to navigate" is thrown, which could be misleading.

Also there is some speed difference between wikilink-fslink and direct fslink, I am not sure why or whether reproducible.

5

Yes the failed to navigate error is a bit misleading, it stems from an implementation detail and isn't completely wrong "Couldn't find document editor", I couldn't think of a no hack solution to this when I implemented it.
Yes, it does open it in a new tab, but this is the case for any link leading to a third party, they all open in a new tab, this is also true for your solution. It uses the exact same navigation logic as the default fallback behavior.
The speed difference probably stems from the fact that it tries to find if there is a document editor for that file. It should really not be that big of an issue, navigation should still be plenty fast

1 Like