Previous Scripts for Using Hook With EagleFiler



In Hook’s original support for EagleFiler, Hook’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’d open a file stored in EagleFiler in any other app than EagleFiler, and then invoked Hook, Hook 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 Hook integration scripts version 102, Hook 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 Hook will normally still be able to resolve the address to the file.)

Previous EagleFiler integration scripts

For anyone who would like to Hook 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 Hook 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 Hook 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 Hook 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 it was not particularly general. What if you wanted to create a new OmniOutliner or .txt file stored in an EagleFiler database? Moreover, it would suffer from the same issues described above for addresses.

After 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 Hook 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”, Hook 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, Hook recognizes each post as belong to the same topic, so when you invoke Hook on a topic, it will present all the URLs. (You can try this for yourself Hook-linking several posts on https://discourse.hookproductivity.com/, such as this one. Notice that as you scroll up and down, the URL changes. But Hook serves the same links.)

Currently, EagleFiler lacks a function that would allow Hook 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 Hook assigns a single address for each resource of an app.)