A Reflection on URL schemes

maclm

@ctietze, maybe I shouldn't have posted this here, feel free to move this to "Meta" if you feel it more appropriate.

This thought was triggered by Link Behaviour from @TonyWilliams.

While I would love to see something like thearchive:// or shorthand like ta:// being implemented, I've always been hesitant to use nvalt://find/some%20search%20term.

On the bright side, I find it immensely useful to be able to call nvALT from outside of it.
On the dark side though, what if/when nvALT goes away ?
I'm afraid of getting left in the dark, alone with my links pointing nowhere anymore.

Is there a way for a developper to expose app preference/setting that would allow the user to say "support/handle xyz://customURL format" ?

Or is there a way for the user to customize that at the OS level ?

[[wiki links]] are great inside one app, be it The Archive or nvALT. But what can we use from the outside that would be reasonably future proof ?
I'm curious to read what strategies others are using for that use case.

ctietze

Here's a secret: wiki links and hashtags utilize a URL scheme already

These are implemented at the moment and may change in future versions:

• thearchive://search/<TERM>
• thearchive://match/<TERM> -- like search but displays good fits
• thearchive://matchOrCreate/<TERM> -- like match but creates a note called <TERM> if nothing was found

As for the customization -- I'm not sure, but I'll look into it. It's probably unlikely that users can customize this directly because the URL scheme setting is bundled with the app. There is no limitation from macOS regarding URL schemes, though, so I could add support for nv://, too, except it's considered bad practice if you don't stick to your own.

maclm

@ctietze said:
hashtags utilize a URL scheme already

Ho, interesting. Given what I read from you about hashtags in this post, I wasn't excepting hashtags to work in TA.

These are implemented at the moment and may change in future versions:

• thearchive://search/<TERM>
• thearchive://match/<TERM> -- like search but displays good fits
• thearchive://matchOrCreate/<TERM> -- like match but creates a note called <TERM> if nothing was found

This is indeed good news. Even though the same due diligence and caution mentioned above about nvALT apply.

it's considered bad practice if you don't stick to your own.

This seems both debatable and reasonable. So I won't debate it.

I'm curious to read what's your take on cross-documents linkage though. I remberber reading about your §bookmark system and I figure that's great inside nvALT or TA but I'd like to know what you do when it comes to get out of those apps.

ctietze

Since you know the §-stuff already, you also know that it's just another convention that works with plain Markdown, provided someone (the app) takes care of defining the link.

On its own, this is just text to the Markdown renderer:

Some text foo bar, but [also interesting][§201705310725].

But this will work:

Some text foo bar, but [also interesting][§201705310725].

[§201705310725]: file:///Users/foo/archive/201705310725%20the%20note.txt

But as far as the actual work inside the archive is concerned, [[201705310725]] should do the trick better. (It's using the thearchive://match/<TERM> URL, by the way.) It's quick to use and more forgiving. Then again, you'll need a pre-processor to get rid of these links if you concatenate notes using the amazing outline script, for example.

Sascha

As long as the files your are linking are available to the system wide search you'll be fine. Just search for the ID.

Example: If you want to link from nvALT (or any txt-file) to a pdf document. Give the document a identifier in the file name and put it into the pdf filename. You can follow the reference by just searching for the identifier via system search.

(If I understood your issue correctly)

maclm

@ctietze I'll sure give your script a try.

@Sascha while your approach doesn't give us clickable links, it is certainly more future proof and tolerant to files being moved or renamed (as long as the ID remains untouched). I like it.

file:///urls are hard to read, because of URL encoding (%20), totally obscure to Spotlight and easily breakable by nature.

You guys are awesome.

Sascha

@maclm I believe that this will be always the case. Clickability is bound to software features. Therefore, I decided to use only techniques that a baked into the concept of having a computer. This means *.txt, text and a search.

Messing with the ID falls under human error.

ctietze

@maclm I got links from fellow tester Bruno Conte regarding custom URL schemes which he was about to use:

• macOS: https://superuser.com/questions/548119/how-do-i-configure-custom-url-handlers-on-os-x
• iOS: https://stackoverflow.com/questions/8201724/how-to-register-a-custom-app-opening-url-scheme-with-xcode-4

Migrating could be easier than I thought!

If one of you folks wants to experiments with this and package an nv:// redirection to thearchive://, I'm of course very happy to help distribute the result

maclm

@ctietze it's good you putted them here. If I ever find the time to dig them but can't promise anything for now.

In the meantime though, I'll resort to UIDs for the reasons mentioned before.

ctietze

With the recent changes to the app, I wonder what else you need a URL scheme to to. It’s a great way to remote control an app from anywhere, albeit more limtd than AppleScripting.

Some things I did consider but not decide on:

• add a query parameter to pass in words that should be highlighted (if highlighting is enabled in the preferences)
• matchOrCreate could take an optional note body text to insert if a new note has to be created (think templates!)

marsalcrow

It is hard to say anything in general for schemes , because they are wildly different. In many cases the name of the scheme is the name of a protocol which can be used to fetch the resource (like http, https, ftp etc.) but that is not hard rule, eg. the 'mailto' scheme indicates an e-mail address, but not a particular protocol. Some schemes does not correspond to any specific protocol, like the 'about' scheme used in web browsers, where the resource is not fetched via a protocol at all, but is built-in in the client.