Use case or problem
Obsidian’s Linked Mentions (both the dedicated Backlinks pane and the embedded backlinks footer) labels each result with the basename of the source note. In folder-note workflows, where notes live as some-note/index.md (very common with static-site setups, Obsidian Publish, and folder-note organization), every backlink row shows the same label: “index”. The pane becomes effectively unusable because you cannot tell the entries apart.
For contrast, the outgoing Links pane shows the full path of each target, which is genuinely useful in the same vault. The inconsistency is striking: link targets get a full path, but mention sources get a bare basename.
This also matters for consistency across the app. Many users already treat a property (for example title) or the folder name as the real human-readable name of a note, and plugins surface that name almost everywhere else already: graph view, tab titles, the quick switcher, the file explorer. The backlinks / linked mentions pane is the one surface a plugin cannot touch through any supported API.
Proposed solution
Expose a way for plugins to supply the display text for source rows in Linked Mentions (and ideally Unlinked Mentions), covering both the dedicated Backlinks pane and the embedded backlinks footer. For example, a registerable resolver:
registerBacklinkTitle((file: TFile) => string | null)
returning a custom label, or null to keep the default. Ideally this would reuse whatever internal “display title” resolution Obsidian already applies elsewhere, so results stay consistent across backlinks, tab titles, and the quick switcher. Even a much simpler option, “show the full path instead of the basename in Linked Mentions” (matching the Links pane), would solve the most painful case.
Current workaround (optional)
DOM manipulation via a MutationObserver that overrides textContent on each rendered row. We have removed this from our plugin because it cannot be made reliable across Obsidian versions (the backlinks DOM shifts between releases, and same-basename collisions make correct resolution nearly impossible), which is what prompted this request.
