I’d like to have a command in Terminal that takes a list (or glob) of files, linking them all together. So running hook file1.md file2.md ../maindoc.pdf would effectively create bi-directional hooks on all three files. I see in the AS dictionary how to get a bookmark from the file path, but I don’t see a way to actually create the hook using that bookmark. Am I missing something?
3 Likes
thanks for asking, @ttscoff. Hooking things together is not yet in the AppleScript dictionary, but it is something we plan to add.
3 Likes
+1 for this idea. Would love to see this added. I’ve been watching Hook develop and have a license but have not used it much (yet).
This is interesting. I’m a little unclear. Which outcome are you expecting? A or B or C or something else?
1 Like
Still playing with the idea, but my inclination is to treat it like a cp command, where everything before the final argument is a source, and the final is the destination. So A, in that case. It did occur to me that bidirectional linking should be a consideration, I just didn’t take it any further without knowing if it was going to be possible at all :).
1 Like
Why not see it as ln -s a b. So basically you have a directed link pointing from b to a. It’s only partly an analogy, as for ln, b would be created at this point. But OPs requirement could then be realised with a couple of such calls.
(This is excellent. I’ll keep you posted on what I do with it when I have a chance to get back to it!
1 Like
Ok, I have a rough version of a CLI ready. You can find the code in the GitHub repo, and it can be installed with gem install hookapp (or sudo gem install hookap if that doesn’t work).
hook help will show all available commands, and you can use hook help COMMAND to get detailed info and options for any specific command. I’ll do a bit more documenting on the GitHub README as I go.
One issue I’m running into, @LucB, is that when I trigger the AppleScript command bookmark from URL on a Hook URL to an email, it comes up with a blank title. It seems to work fine for file paths, but gives me nothing to work with for other hook urls. Am I using the method incorrectly?
When creating a bookmark via Hook’s bookmark from URL API, one can and perhaps should include the title. Hook does not try to determine the title, as the URL might point to a remote resource about which Hook does have info in its DB. Hook does not make calls to web servers, for instance, to get titles. It asks the client app , if any, for that information. Or in the case of email, the mail client might not be running.
Perhaps Hook’s AppleScript dictionary should be more descriptive, – it’s currently quite concise. Also, CogSci Apps should provide some documentation with usage examples. We will point to your work, Brett, as usage examples.
The client could query Hook to get the title associated with a URL, if any. Or the client app could use curl or other mechanisms to get title information, as the client app is not running within the context of Hook.
related: we are considering having Hook equivalent of ‘services’, which would extend the contextual services available for particular apps. but that’s for a separate forum topic.
But these aren’t hook links I’m creating in the CLI, I’m just referencing links that were already copied by Hook. Example:
I go into MailMate and invoke Hook on an email message, hit ⌘C. At this point if I go and invoke Hook on a file and ⌘V, it creates a hook with the subject of the message title. If I instead go to the CLI, it creates a hook with an empty title.
Looking at the result of “all bookmarks”, it seems like the title should be stored at the time the hook is copied, right?
-Brett
Here’s a good example where I’m confused:
I just added a from subcommand that uses bookmark from active window to activate a given app and get a hook from it. When I run that with MailMate, the hook that’s returned has a title and an address. So I copy the address from the returned hook into the clipboard.
My expectation is that when I use bookmark from URL on that address, the associated title is still available in the bookmark object that is returned.
What I actually get is a bookmark with no title or path, just an address.
I understand that just using bookmark from URL on a random URL would require a title to be provided. But if the address in question had already been created using Hook, shouldn’t that title be accessible by running bookmark from URL on the same address? This is where I’m confused, and maybe there’s a method missing?
-Brett
Ok, further info. Using bookmark from URL "THE_URL" title "THE_TITLE" does not return a bookmark with a title, still just a bookmark with address only. So that’s not working as advertised.
I did note in some experimenting that if I just copied a URL from MailMate via Hook, running bookmark from URL on the address in the clipboard did NOT return the title that had been visible in the GUI. But if I then used Hook to link that URL to another item, then running bookmark from URL returned the title. So — and this may be exactly how it’s supposed to work — it seems like a hook bookmark isn’t actually stored until the link is applied to something.
I think it should be, though. If a URL is copied by Hook, the relevant details for that bookmark should be stored and accessible via URL without it having to be applied first. There’s probably a good reason that it doesn’t operate that way and I’m missing it…
Sorry for the confusion. I may have mentioned this somewhere on the forum (but possibly not), but I should clarify on the API page which is currently far too concise:
Currently Copy Link only creates a bookmark in Hook’s database if it is called on a file, not other types of resources. That is something we are fixing in 2.0 (due this summer) as we expose more of Hook’s truly universal bookmarking functions. I.e., Copy Link should add a bookmark in Hook’s DB regardless of the item type. We also intend to add a UI function “Add Bookmark” which adds a bookmark without putting it on the clipboard.
More broadly re our rationale: That will enable users to use Hook as an implicit universal bookmarking tool. That is consistent with our mission, to help users access / re-access pertinent information. (I think I mentioned this idea in the CP books that information that one has accessed once is immeasurably largely more likely to be pertinent to the user in the future than random information on the Internet. Hook’s job is to help people get that info.)
I wrote ‘truly universal’ above because currently 'universal bookmarking" as an expression on the net tends to be used for cross-browser bookmarks (like Pinboard). But Hook is for any addressable info.
Ok, this makes sense. I’ll leave the CLI as is for now, but it will definitely work better in some areas when Copy Link adds other item types. Looking forward to that! I’ll post the version with copy from APP_NAME today, but that subcommand won’t be super useful until it can actually get a bookmark with a title from it.
This is probably a discussion for another thread, but how do you see the Add Bookmark and universal bookmarking tool differing from using tags? Isn’t tagging all about bookmarking, but with a way to add intrinsic searchability to the bookmark? Once you bookmark 1000 things in Hook that aren’t connected to anything else, is it any more searchable than just using Spotlight to find the item? I might not be understanding the goal. I might also be jumping to conclusions :).
1 Like
So as an alternative to bookmark from url automatically creating an entry (with title), a separate command to register a bookmark manually would work.
Also, would there be interest in a link from X to X in addition to link between X and X (one-way vs bi-directional)? Personally I almost always want the bidirectional link, but for parity it might be nice to have the option.
1 Like
I’m finally coming back to your question, @ttscoff . Are you asking whether there is interest for unidirectional contextual links in Hook’s UI, or the CLI?
To sum up the background for everyone:
- In our terminology, ‘hooks’ are bidirectional links.
- Hook’s contextual popup window presents items that are ‘hooked’ to the current context. There’s a ‘HOOKED ITEMS’ section. (2.0 will add new optional sections to the window).
- This context typically starts out as being the foreground resource of the app in foreground when Hook is invoked. But users can navigate within Hook, which changes the context. The context is indicated in the title bar. To avoid ambiguity, we sometimes refer to the ‘title item’.
- Under the hood, Hook does support the creation and retrieval of bookmarks.
- There is also an API to retrieve hooks, which are bidirectional.
- At the “view layer”, Hook’s contextual window (pre upcoming 2.0) does not yet expose bookmarks or unidirectional links.
However, Hook 2.0 will expose bookmarks:
- There will be an “Add Bookmark” command.
- Whereas pre Hook 2.0, only
Copy Linkon files adds an underlying bookmark, as of 2.0+ every call toCopy Linkwill add a Hook bookmark. We’ll communicate that. - Users will be able to search for all their bookmarks within Hook, meaning they won’t need to use an external tool (like ObDev’s LaunchBar, and Running with Crayons’ Alfred).
However, Hook 2.0 will not (yet) support unidirectional contextual links (i.e., links that show up in Hook window in context of a particular resource). We do see a ned for them, however, and they are planned but not scheduled. There has not been a big demand for them, and they don’t IMO compare to the other big items (such as Hook for iOS) in the pipeline. But to repeat we recognize their usefulness, and we acknowledge there’s an extremely wide range of ways in which Hook is being /can be used.
We have not committed/published how Hook will support unidirectional links – i.e., that is currently undefined.
Like I said, I generally always want a bidirectional link. I think I misunderstood some behavior I saw in the GUI and came to believe that unidirectional links were possible, though I wasn’t sure how it was happening. Chalk it up to my own confusion as I explored.
I do look forward to the Add Bookmark command, as you add the more complex browsing and search options I think it will be very handy. And being able to generate, search, and reference a bookmark object directly in AppleScript will make the CLI more useful as well.
-Brett