Hi, this might be a bug:
- Hook some things together and change your mind: no, I don’t want those hooked.
Unhook those things and change your mind: finally, I do want them hooked.
- Hook them back together and change your mind: no, I don’t want those hooked.
Delete their link, and change your mind: finally, I do want them hooked.
- Hook them back together and observe that it would be expected to see their hook appear, but Hook doesn’t actually accept hooking up items after having hard-deleted their link.
Obviously, steps 2-3 are superfluous in this repro.
It’s just that it’s nice that they’re reversible, and it’s not nice that 4-5 don’t work the same way.
BTW I discovered that after unhooking some items and being very surprised to see them still appearing in my bookmarks. I then realized what I’ll want more often (at least while I trial stuff in beta releases and struggle to discover and establish workflow habits with some apps I’m trying out) is to hard-delete those links. And oftentimes, I’ll afterwards want to re-link the items… but can’t for now due to this bug (if it really is a bug).
Sorry for the trouble. I am trying to reproduce the problem but no luck so far.
Could you please let us know the types of bookmarks (e.g., web url, file, mail, etc) for hook and unhook? And the titles of the bookmarks. If you can provides us with some screenshots or a short video, that would be very helpful.
Thanks for the investigation.I should have done that in the first place.
The first video isn’t the same thing, but another issue I got while reproducing…
The second video, below, is the repro I documented above:
After these 2 videos, it’s interesting to note how my recent bookmarks are:
that is the designed behavior. Hook is meant to make it easy to re-access information later. To support that with respect to searching, we bookmark on hooking. Hooking is one of several ways to add bookmarks to Hook per Universal, Effortless, Contextual, Linked Bookmarking – Hook. Another example in a traditional bookmark manager would be adding meta data to a bookmark. We wouldn’t want the bookmark to disappear just because the user cleared the meta-data. A use case in Hook is that it would still be possible to find that bookmark and easily hook it to something else, or pin it, rename it, etc.
Information that one has touched with hook stands out from the the possibly 100K other resources one has accumulated on one’s Mac. It’s a signal relevance.
Luc, this line of thinking is pure gold with profound productivity implications for our future selves. It never fails to make a strong impression on me (every time you make me rediscover it).
Still, is that supposed to happen after each one of the two kinds of removals (unhook vs delete link)?
My use case might be rare, but not that rare: when struggling to understand and get used to Hook, one might hook stupid things together, just like I did in these videos (self-hooking). And the other day when I was scripting NotePlan (there’s something off with this app’s integration, though - I should make a movie in another discussion), I ended up with many links in my bookmarks that I didn’t want to persist there. I thought: oh, I should have hard-deleted them during my experiments, instead of just unhooking them. But now I’m not even sure if hard-deleting them would have removed them from the bookmarks at the same time. Or just greyed them out (is that logical deletion?)
I could find again the documentation that explains the difference between unhook and delete link, but I remember that I didn’t fully understand the implications the few times that I read them in the past. So I figured I need to try it out to build myself an intuitive understanding instead.
Since 3.6 or so, we use the term “delete” for completely removing the bookmark (record of that particular unique URL in Hook). If you delete a bookmark, then every hook to that URL (bidirectional link) will be taken down with it. We’ve reserved the term ‘unhook’ for removing the bidirectional association between two bookmarks (URLs). I’ll return to the topic.