Environment: Hookmark 7.2.2 (build 6644), macOS 15.7.4. Large library — 67,828 bookmarks; 39,810 rows in fileinfo, 122,365 in link.
RELATED is reliably populated when I invoke Hookmark on a web URL — twenty or more genuinely useful items, across ChatGPT threads, Obsidian notes, Things tasks and files. On a file, it is reliably empty. Same library, same session, minutes apart. The app the file is open in makes no difference: Finder selection, TextEdit, FoldingText — all empty.
What I checked before posting:
| Check | Result |
|---|---|
| Section hidden? | No — hide.related.items cleared; HOOKED and INDIRECTLY HOOKED both populate for the same file |
| Bookmarks in the subject file’s own folder | 191 (a second test file: 527) |
Subject file’s rows in link |
3, all present in fts54 |
fts54 MATCH '<token from the filename>' |
259 rows, 104 of them file links |
| RELATED shown | 0 |
So the neighbours exist, they are bookmarked, and the live index returns them. The panel just does not show them when the subject is a file.
One input does work for files: a file carrying a Hookmark tag shared with five other items returned exactly those five in RELATED. So tag-matching is fine — it is the HOOKED NEARBY / title path that is silent for file subjects. Per Definitions Please, “shares part of the URL path” is meant to apply to hook://file/ as well as http(s), which is what made me think this is a bug rather than by design.
Possibly unrelated, possibly a clue: there are two FTS indexes over the same content view. fts54 is current (122,365 rows, trigram tokenizer). fts52 uses a porter tokenizer and stops at rowid 17,525 while link runs to 161,935 — it looks like an abandoned migration. Harmless if nothing reads it; a silent failure if anything still does.
Happy to run any query or send a redacted extract if it helps.