In Hookmark’s original support for EagleFiler, Hookmark’s Copy Link and Copy Markdown Link would return EagleFiler native addresses (URLs), i.e., of the form x-eaglefiler://open?library=<...>. However, this had the drawback that if you opened a file stored in EagleFiler in any other app than EagleFiler, and then invoked Hookmark, Hookmark would not be able to show you any of the links associated with the x-eaglefiler address. This meant that you could accumulate two sets of links to (and from) the same resource: one that is associated with the resource’s x-eaglefiler address (URL), the other with the resource’s hook://file address (URL).
So, as of Hookmark integration scripts version 102, Hookmark instead always returns a URL of the form hook://file/<id><path><terminal-node-name>, such as: hook://file/f0C6HfPuH?p=aW50ZWdyYXRpb24tbW9yZS9FYWdsZUZpbGVyLWludGVncmF0aW9u&n=original-integration-between-Hook-and-EagleFiler.txt. This gives you the full power of hook://file links (you can rename the files, move them, etc., and Hookmark will normally still be able to resolve the address to the file.)
Previous EagleFiler integration scripts
For anyone who would like Hookmark to interact with EagleFiler the way it used to (before version 100 of the integration scripts), here are the previous integration scripts.
Open Item
Before version 101 of Hookmark integration scripts, there was no open item script for EagleFiler.
Get Name
tell application "EagleFiler"
set _records to selected records of browser window 1
set n to count of _records
if n ≥ 1 then
set rec to item 1 of _records
set _file to rec's title
end if
end tell
Get Address
Before version 101 of the Hookmark integration scripts, the Get Address script would return a x-eaglefiler:// URL, as follows:
tell application "EagleFiler"
set _records to selected records of browser window 1
set n to count of _records
if n ≥ 1 then
set rec to item 1 of _records
set _file to rec's URL
end if
end tell
New Document
Before version 101 of the Hookmark integration scripts, “Link to New” > EagleFiler would create a new .rtf (rich text format) file in EagleFiler as follows:
tell application "EagleFiler"
tell library document 1
set {_record} to import text "$title" with allowing duplicates
set _record's title to "$title"
return _record's URL
end tell
end tell
This was helpful, but not particularly general. What if you wanted to create a new OmniOutliner or .txt file stored in an EagleFiler database? Moreover, it suffered from the same issues described above for addresses.
Since version 101, no special “Link to New” is required. Users can set the default “Link to New” folder to an EagleFiler watched folder or EagleFiler library.
Future possibilities
In the future, it may be possible for Hookmark to use (unify) multiple addresses (URLs) for the same resource. These URLs may be thought of as “synonyms”, or different handles, for the same resource. In fact, “under the hood”, Hookmark already does this kind of thing in some circumstances. For example, each post in a topic served by discourse software has its own URL. For many forums, Hookmark recognizes each post as belong to the same topic, so when you invoke Hookmark on a topic, it will present all the URLs. (You can try this for yourself by Hookmark-linking several posts on `https://discourse.hookproductivity.com/`, such as this one. Notice that as you scroll up and down, the URL changes. But Hookmark serves the same links.)
Currently, EagleFiler lacks a function that would allow Hookmark to unify the x-eaglefiler://open?library=<...> address with the hook://file/ of a given resource, but this might come in the future.
In fact, CogSci Apps may extend its integration script framework to enable all Pro users to provide custom support for multiple addresses per resource for any app. (Pro users can already define how Hookmark assigns a single address for each resource of an app.)