I am finding that Ulysses is forgetting links after a reboot. The other end of the link seems to be remembered, but when using it a different Ulysses note is selected (the current one I think) and a text-indent is performed. Invoking Hook in Ulysses lists no links.
I believe so — I haven’t had a chance to consciously test it under the new build but it’s likely they are from an older build. I was assuming this wouldn’t make a difference as it’s only an issue with Ulysses so I assumed it’s a scripting issue not a build issue.
I’ve found the problem, and it’s on Ulysses’ side.
If a Sheet is in an iCloud or local Library, then the ID remains stable as you move it around. But if you move a Sheet between an iCloud and local Library, then the ID changes and breaks therefor Hook can’t track it. This is an issue for me as Hook notes are created in my iCloud Ulysses inbox, but for data security, I then move work-related notes to a local library.
I suspect this is a limitation that will remain.
I’m going to try and use the Spotlight search link feature to see if that’s workable in this scenario. I’ll have to move the note just created then relink it to the current context.
Thanks for letting us all know, Steve.
Re links to Ulysses docs
If Ulysses would implement a redirect one could get back to the original Ulysses note. That would solve half the problem (but not solve the following).
Re links from Ulysses docs
- If the new URL assigned by Ulysses followed a known pattern, then it would in principle be possible to map the old URL to the new one. I checked and couldn’t detect an obvious pattern; but hopefully there is one that the Ulysses folk would be willing to share; or they could update their code to deal with this issue.
Hook links are already quite robust (more so than aliases even), and we intend to continue expanding our coverage of edge cases, which may cover this Ulysses situation. Still, hopefully Ulysses developers will improve their automation and URLs to facilitate indexing, access and other customer/third-party integration.
Would it make sense to you, and others, if when creating a New Document (in Ulysses or otherwise) as well as inserting the title it also inserted a Hook URL to the original context?
That way, whatever happens you can at least get from a note to its context. You could also generate a Hook link from the context then spotlight search it to find the disconnected note.
It wouldn’t look as neat but would add a layer of robustness.
(NB: I have found doing a Spotlight search on the title generally takes me straight to the original context when the links have broken in Ulysses).
That’s a hassle and too bad!
If you have more than one link to a sheet, you can copy them all at once with Copy All Links (⌃⇧C) to link (⌘L) with the moved/new sheet.
When you use “Link to New” to a Finder file, Hook already adds xattributes. You can see them with
xattr -l <filename>. Doesn’t apply to items in database apps of course.
If Ulysses automation were up to it then AppleScripts could be tweaked for (optionally) adding a linkback in markdown comments of new docs, like
<!-- [Ulysses forgetting links - Bug Reports - Hook Productivity Forum](https://discourse.hookproductivity.com/t/ulysses-forgetting-links/498/5) --> or
[comment]: <> ([Ulysses forgetting links - Bug Reports - Hook Productivity Forum](https://discourse.hookproductivity.com/t/ulysses-forgetting-links/498/5))
To deal with Ulysses changing the URI of docs, one could also perhaps add the URL of the current document as a markdown comment. Something could be piggy-backed onto that in the future.
I’m just throwing this out there.
Actually, I think one can actually use Hook’s Search links to work around the current problem. If you plant a Unique ID in the Ulysses document, then you can create a Search link from the ID, and you can link any linkable item to this search link. This would work for both hook:// links and bidirectional Hook window links.
This assumes that Ulysses docs are indexed by Spotlight. In my tests that seems to be the case, but I’m not an avid Ulysses user.
The rest of this entry deals with how to make such search links look better in the ACCESS LINKED ITEMS section.
Readability of search links to ID’s planted in documents (such as Ulysses docs)
For the moment for usability you might wish to name the search link meaningfully so that you can tell by looking in the ACCESS LINKED ITEMS section of the Hook window what Ulysses file you are looking at. E.g.,
E.g., if the file is called
Foo Bar Baz you can create a search link from
Foo Bar Baz A859N→ hook://search/?q=Foo%20Bar%20Baz%20A859N. Not very pretty. But it does provide the title.
A bit of AppleScript would yield a nicer Unique ID based on the title of the document, like Foo-Bar-Baz, which would give a Hook search link like this: hook://search/?q=Foo-Bar-Baz , which is more readable.
But better… a function could return a markdown link based on the document. In which case the title could appear in the ACCESS LINKED ITEMS section (on the other side of the link to the Ulysses doc) indistinguishably from what you currently get:
[Foo Bar Baz](hook://search/?q=Foo%20Bar%20Baz%20A859N).
i.e., (a) I.e., one would need some AppleScript to return a pretty markdown search link based on the title of the current item, and (b) CogSci Apps would need to improve how Hook displays links in the ACCESS LINKED ITEMS section that were forged from markdown links copied straight into the clipboard (i.e., that do not originate from Hook’s
Copy as Markdown Link .) The (b) task I think CogSci Apps should do regardless of this issue (I will need to discuss with others at CogSci Apps) as it will be handy in many contexts, one of which I’ll elaborate on later.
As long as the ID is relatively unique, and all Ulysses docs are indexed by Spotlight, the links would be robust regardless of Ulysses’ lack of automation and its changing URLs of docs.