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!)