Workflow suggestions - anchor points, app vs file links

Discussion & Help
1

I have two (somewhat related) questions regarding workflow options.

First, let me explain my preferred workflow:
I have a an anchor (starting) to-do document in nvUltra that links to my current (4-5) project folders, which in turn links to various resources. This anchor document is the first thing I open every day.

  1. I use two text editors (nvUltra and BBEdit), but when making Hook links to a file in one editor, the links don’t show up if I open up that file in the other editor (probably by design).
    An option of making the Hook links in an editor follow the files regardless of which editor one uses would be useful.
    I could of course make a duplicate set of links for the second editor, but that is double work. Another option would be to use Finder files as a starting point, instead of the files via the editors, but again that would be double work. And necessitates an superfluous anchor point to navigate to my intended anchor point…

  2. I’ve seen some feature requests for having a anchor point when invoking Hook. Of course when starting up ones Mac, the starting point depends on which app/document comes in focus when startup is complete. More often than not that means I have to navigate to my anchor app/document to get started.
    I get around this by using nvUltra (shift-cmd-U) and then it always has the last document in focus, but when needing more than one anchor point it seems more natural to let Hook be the “launcher” each day.

It would be nice to just invoke Hook and then there would be a menu item for one or more anchor points. In my case that would be nvUltra and that to-do document combo.
And then some way of switching (via Hook) between apps for the same document without the double work mentioned above

Any workflow suggestions to remedy my woes, would be greatly appreciated. I might have missed a point or two about the Hook functionality :wink:
Otherwise, treat them as feature requests.

2

Sorry for the delay in responding, @loseth. Normally, when you open the same document in two different apps, you should see the same links.

Exceptions currently happen when the app has its own URL scheme and when the Hook scripts in use work with that URL scheme. nvALT has its own URL scheme, which Hook respects. Here is an example. there is a file currently named “topic-1257-example1…txt” in a folder that nvUltra scans.

  • from nvUltra the result of Copy Markdown Link looks like this: [topic-1257-example1..txt](x-nvultra://open?path=/Users/lucb/Dropbox/nvAlt%2C%201writer%20Dropbox%20folder/&note=topic-1257-example1..txt)
  • from Finder or most other apps (including BBEdit), the result looks like this: [topic-1257-example1..txt](hook://file/gl6gyLYWI?p=RHJvcGJveC9udkFsdCwgMXdyaXRlciBEcm9wYm94IGZvbGRlcg==&n=topic-1257-example1..txt)

I’m sure that’s the kind of difference you’re seeing.

With most apps that operate directly on files, Hook returns a hook://file URL. We use the hook:// scheme for files because we’ve designed some logic to make them more robust that file:// links (e.g., you can normally move and rename the files without breaking the links).

In EagleFiler, for example, we’ve chosen to make the default scripts return hook://file links rather than EagleFiler:// links. But we also have published scripts to use the EagleFiler:// links if users would rather use that.

In the future, we expect to provide a mechanism to allow matching of URLs, a way to treat different URLs as equal. (Special cases of this are already in place for some web links).

If you do not need nvUltra:// URLs, and would be just as happy with hook://file links, then a solution would be to modify the scripts for nvUltra such that the “GetAddress” script returns hook://file links. Then the address would be uniform. (I’ll need to check whether we have one in stock. Someone else on the forum might already have done that.)

One convention is to enable “Hook” Finder tagging and to have a smartsearch in finder that filters for files tagged with “Hook” . The next result of Hook will allow you to set the “Hub” flag for any resource. Our plan is for Hook’s upcoming “Library” window (whose final name is not decided) to have a section for hub resources. As an interim measure, we could have an advance preference to apply a “hub” Finder tag to file resources that are marked as “hub” (and to remove it when the tag is unset). That would allow users to create a Spotlight search in Favorites (Finder sidebar) to show all File hubs. (Hook’s solution will be more general, enabling any resource to be a Hub; at least that is the current plan).

To be clear, our current plan is roll this out iteratively. First the “hub” status will be shown in the contextual window only (because the Library window does not yet exist). Then it will be shown in the Library window. We receive suggestions and do sometimes adapt our plans accordingly so this is not official till its published in the app.

That I think will address the “anchor point” concern.

I’ve written this out quickly before bed (late Sat evening here) and will check it over in the morning.

3

@LucB, thanks for the explanation for the nvUltra links and the information about Hooks upcoming Library feature.

The latter will definitely solve my problem regarding multiple anchor starting points.

As for the former, I’m not sure where that “GetAddress” script is located?
I’m furthermore unsure what effect it will have on nvUltra if I change to Hook file links for nvUltra - I’m afraid to break any functionality in nvUltra…
I’ll ask the last question in the nvUltra forum

4

It’s the Scripts Tab of Hook’s Preferences page. The Scripts tab is where users can see and configure scripts that control the interaction between Hook and other apps. (Some apps are not listed there because they work with Hook’s underlying generic interoperability.)

This does not affect nvUltra itself. It just affects the URLs returned by Hook when you invoke Hook and choose the Copy Link or Copy Markdown Link functions. I.e., if you were to change Hook’s “Get Address” script for nvUltra to return hook://file links, then the URL part of the Copy Link, and Copy Markdown Link results will be different (when Hook is called in the context of a nvUltra resource).

Hook’s current Get Address script for nvUltra currently uses nvUltra’s native URL scheme. (Our general principle is to use the app’s addressing scheme if it provides one. In rare cases, the hook:// file scheme is used despite the app having its own scheme. However, as I noted we have provided alternatives, and Pro users can apply them.)

Whether you are using Hook or not, when you activate an nvUltra:// link (anywhere in your Mac account), macOS invokes nvUltra to deal with it. When you open a hook://file link, macOS invokes Hook; Hook resolves the URL and sends the request back to macOS to open the file. What happens then depends on your macOS account configurations. Typically, that can be predicted based on the extension of the file. E.g., BBEdit might be your default app for opening “.txt” files. But macOS can be configured to make more specific decisions for particular files (e.g., Choose an app to open a file on Mac - Apple Support). On my Mac, for instance, BBEdit is the default for .txt files. But I have a bunch of files that end with .txt, which my macOS account opens in TaskPaper (which is good).

I mention all this because if you change the scheme of links returned in Hook’s nvUltra Get Address script to hook://, those link targets won’t necessarily be opened in nvUltra anymore. We could have coded Hook to allow additional Hook-user-guidance about opening files; but that would have introduced additional complexity for the user – macOS already does a great job. (Providing a way to treat different URLs as equal would address the issue you raised of not seeing the same Hook window links for the same resource when it is opened in BBEdit vs. nvUltra. Again, this issue does not apply to the vast majority of apps. And in any case the URLs you get from Copy Link are still valid – as long as they are respected by the app that generates them.)

I myself use nvUltra and BBEdit. I tend to only use nvUltra for the files it manages, but sometimes I will open them in BBEdit. Hook has a Reveal File in Finder function that allows one to see the file, and then take whatever action one likes, e.g., to open it in a different app, invoke Hook on it, etc.

In terms of a workflow for using nvUltra and BBEdit together, you might want to have a rule such that you only create Hook window links in one app or the other. Using Hook in a non-nvUltra context will give you the more general (hook://file) URL. You can also insert URLs in comments in any markdown file, regardless of the app.

5

This is really useful information Luc, now I can continue to build my workflows around the apps I use - Hook, nvUltra, BBEdit, Marked, iThoughtsX and Deckset.
Thanks again, you’re all doing wonderful work!

1 Like
6

Dear LucB,
This may be a rude question, but I would like to know where did you get nvUltra.app ?
I send my request as a ß tester to BrettTerpstra.
I can not get a ß-nvUltra, yet.
How can I get or where could I get nvUltra.app?
Quite long time, I used to use a nvALT.app.

I look forward to hearing from you at your earliest convenience.

Yours, WAKAMATSU

8

Dear quorm,
Thank you for the feedback.
Yours, WAKAMATSU

9

@quorm om I’m curious to why you think nvUltra is not worth waiting for?
Is it the app functionality or is it the workflow that it requires (all text files in a single folder)?

10

This is far off topic for the Hook forum. Sorry. Deleted my comment. PM me if info is needed.

1 Like