Handling Markdown Images

I’ve only just started to explore (the paid version of) Hook and I think I can see how it could be useful, but I don’t think I understand something which is really basic (and judging from the lack of posts on the issue in this forum, is perfectly understandable to everybody else :-))

That is: how do you get markdown image links to work? I follow the normal procedure (select the image in Finder, bring up Hook, cmd-M to copy the link, move to the markdown document, cmd-v to copy the link) and the hook: link is copied exactly as expected, to which I add the ! to get a standard image link.


But the image is never rendered in the preview in any standard markdown capable app (e.g. DT3, iA Writer etc), which I assume can’t be the intended behaviour. I must be doing something wrong, or misunderstanding something very basic, sorry…

What am I missing please? Or are hook: links simply not fully markdown compatible?

Thanks for any help!

1 Like

Welcome to the Hook Productivity Forum , @brookter . That is an excellent question. I don’t think we’ve discussed it publicly yet, but it is up to the markdown app developer to support this kind of URL scheme, which is quite feasible using our AppleScript API. They can use the specified hook://file/ URL to determine the file path (obtain a file:// URL).

We heard from at least one such dev that they plan to include that, but we will let them make the announcement.

updated 2021-08-23 14:41 adding:

Here is an example script to get the path for hook://file/ urls.

tell application "Hook"
	set bks to every bookmark whose address is <hookFile>
	path of item 1 of bks
end tell

Replace <hookFile> with the hook://file/ URL.

i.e., path of <hookFileURL>.

I’ve tweeted to this thread here https://twitter.com/HookProductvT/status/1429908838417829889 . One could retweet while @ mentioning one’s favorite markdown app there, and they can ask questions here if they have any.

Thanks very much for the reply.

So it’s a matter of waiting until markdown previewers recognise hook links? That doesn’t really seem to be a sustainable solution long term, expecting an entire class of software to be enhanced to retain core markdown preview functionality for a third party link format. Is that realistically going to happen?

Everybody who uses images in Markdown files must come across this problem as rendering images is an essential part of the spec. How do people get round this issue?

Do they just accept that images are treated differently and remember to import them using traditional non-Hook methods (losing the linking)?

Or do they just give up the idea of viewing images without having to click first because the hook associations are more important?

Thanks for any advice!

Are we talking about rendered Markdown? Or raw Markdown?

(I don’t know whether Hook can cope with spots in a text file but it seems much more likely than (app specific) hooks to rendered document sections.)

My original question was about rendered images. E.g. in the screenshot below, the code on the left (first a standard markdown file: link and second a hook: link to the same image), produces the result on the right.

Unless I’ve misunderstood something, this essentially means that at the moment hook links can’t be used for images which are intended to be rendered inline in the standard way, which seems to reduce the attractiveness of Hook as an option for markdown files (in that you have to remember to use different link methods for images. I had thought that one of the main attractions of Hook was that you only ever needed one mechanism to import links, but that doesn’t seem to be the case.)

So I was hoping to understand how people get round this problem (or to be reassured that I’m just misunderstanding it!)


Hi @LucB, would you be free to discuss this? I’m trying to make this work for Tinderbox. I’m not exactly sure where to start.

Welcome to the Hook Productivity Forum , @satikusala. Thanks for asking.

For the OP, one could write a CLI that takes file1 as input and returns file2. For every instance of hook://file/ in f1 , in f2 it would replace it with a file:// URL . f2 would in other respects be identical to f1. I’ve raised an issue internally re this.

For Tinderbox, I believe in the Tinderbox Meetup on 19 Feb 2022, a request was made to handle hook://file/ URLs. Someone in attendance mentioned that it would be possible to add a hook://file/ field in a Tinderbox note, and have an action that populates an image field with the hook://file/ value.

We see Hook as supplying the missing links and doing the various things mentioned on Hook’s homepage, benefits page and features page. For an app to parse links of any protocol, including hook://file/, well, it needs to have code to do that.

as for the implementation, the developers can use the AppleScript mentioned above. We, at CogSci Apps, might also provide an x-callback-url that takes a hook://file/ URL as input. Just a different way to do the same thing.

I tried the suggested AS:

on getFilePathFromHook(theHookAddress)
	set myPath to "no path"
	tell application "Hook"
		set bks to every bookmark whose address is theHookAddress
		if bks is not {} then
			set myPath to path of item 1 of bks
			set myPath to "not found"
		end if
	end tell
	return myPath
end getFilePathFromHook

I miss where to place this method - because before returning the created note in the “new item” script the bookmark is not there…

complete script:

use AppleScript version “2.4” – Yosemite (10.10) or later
use scripting additions
use framework “Foundation”

set myMacPath to getFilePathFromHook("$user_link")

tell application id “Cere” to activate

tell application id “Cere”
if (count of documents) is equal to 0 then
return “No document is available”
end if

set openFile to file of front document
if openFile is missing value then
return “Hook can’t link unsaved files”
end if

set filePath to my encodedPath(POSIX path of (openFile as alias)) as string

tell front document
if not (exists note “Inbox”) then make new note with properties {name:“Inbox”}
set theContainer to note “inbox”
set myNote to make new note with properties {name:"$title"} at theContainer
set value of attribute “URL” of myNote to “$user_link”
set value of attribute “TheFilePath” of myNote to myMacPath
end tell

set tinderboxURL to value of attribute “NoteURL” of myNote
set tinderboxURL to (text (1 + (length of “tinderbox://”)) thru -1 of tinderboxURL)
set tinderboxURL to “tbx://” & tinderboxURL

return tinderboxURL & “?filepath=” & filePath
end tell

on getFilePathFromHook(theHookAddress)
set myPath to “no path”
tell application “Hook”
set bks to every bookmark whose address is theHookAddress
if bks is not {} then
set myPath to path of item 1 of bks
set myPath to “not found”
end if
end tell

return myPath
end getFilePathFromHook

– encodedPath :: FilePath → Percent Encoded String
on encodedPath(fp)
tell current application
(its ((NSString’s stringWithString:fp)'s ¬
stringByAddingPercentEncodingWithAllowedCharacters:(its NSCharacterSet’s ¬
URLPathAllowedCharacterSet))) as string
end tell
end encodedPath

And if I only created a new item in TBX there is a bookmark in Hook, but the path shows “missing value”. Only if I connect the file to another object (copy+paste in Hook) the path in the bookmark object shows a value

if I use
set bks to bookmark from active window
instead of
set bks to every bookmark whose address is theHookAddress
it seems that I always get the path…

Right. Calling Hook’s AppleScript (in getFilePathFromHook(theHookAddress) in the context of Hook’s “new item” script is not guaranteed to succeed. Hook’s “New Item” script has not finished doing its work.

Thanks for pointing that out, @webline . I’ll need to have a look at that.

I had a look. I was reminded that the default URL scheme for Hook to New > Tinderbox currently is hook://tbx/. This is not a hook://file/ URL at all, so Hook can’t convert it to file:// . The file:// URL is associated with the entire Tinderbox note file.

If you select the Tinderbox file itself (not a particular note) and invoke Hook, Hook will know the file. In that case, Copy Link gives something like: [Tinderbox-01b.tbx](hook://file/9WA8PC6jR?p=bHVjYi9Eb2N1bWVudHM=&n=Tinderbox%2D01b%2Etbx).

Hook could in principle be updated to make Reveal File in Finder work even when you select a particular note, meaning that even in a context of a Tinderbox note object it could figure out the file://

Your prior Tinderbox “Get Address” script does return info re the file path, such as:
Handling Markdown Images - Discussion & Help - Hook Productivity Forum, which you could in principle use to get the file://. So I don’t see why Hook API would be required to get the path. Maybe I misunderstand your intention.

I’m note sure that we talk about the same problem and I solved mine :wink:

If I engage my “new item” script after opening Hook with any file in the Finder using the “Hook to new Tinderbox” command, I get a new note in TBX the $URL attribute contains the Hook URL schema like hook://file/A2fes6AUn?p=ZGV0bGVmYmV5ZXIvRGVza3RvcA==&n=klausur%5Fg3%5F220303%2Epap

The custom attribute $TheFilePath now contains a valid path to the file like: /Users/myname/Desktop/klausur_g3_220303.pap (that’s the result of using set bks to bookmark from active window).

The file in the Finder now contains a Hook link to the individual note in TBX:

That’s all I need!

1 Like

Super! Thanks for letting us know!