Support display of links and unlinked mentions

[AW2307]

Hey, first of all thanks for your contribution. Super cool plugin with tremendous potential!

Is your feature request related to a problem? Please describe.

It would be really useful, if the graph could optionally connect markdown nodes that are linked to each other, or which mention each other.

Describe the solution you'd like

Similar to how a markdown node with two tags is connected to both, if there is a link or unlinked mention between two markdown nodes there would be a connector line. Ideally, there would be a user preference in the global settings to enable one or both.

In the first iteration, no new visuals would be necessary, although offering an option to customize the connector line's color or other visual aspects might make sense in the medium-term. The user could define visuals depending on whether the relation is markdown to tag, markdown-markdown (linked) or markdown-markdown (unlinked mention).

[kctekn]

Thanks for your feedback! Could you clarify what you mean by "unlinked mention between two markdown nodes"? While we can easily detect explicit links between markdown files, it's less clear how we should identify and validate unlinked mentions?

[AW2307]

Hi @kctekn

Thanks for your response.

As I assume you know, there are explicit links and mentions in Obsidian under the "incoming links" and "outgoing links" sections. Unlinked mentions play an important role in my workflow, because they enable interoperability with a certain third-party app. So I only use direct links in some scenarios, and mostly rely on unlinked mentions.

I'm not knowledgeable enough about how Obsidian works under the hood to comment on how the unlinked mentions could best be detected. It's possible that they are created dynamically when the user opens the note, and aren't part of the index, which might make it challenging to incorporate them.

Either way, I think many users would benefit from direct links between markdown notes being included in the graph, and I would be extra happy in case there's a way to also include the unlinked mentions :)

Keep up the incredible work!

[kctekn]

I've noticed that the unlinked mentions feature in Obsidian functions like a full-text search for keywords. However, it doesn't seem to work well in my vault. The lack of accuracy in identifying unlinked mentions can clutter the graph with unnecessary links. It would be a great feature to have in the future, but it needs a more nuanced approach than just basic keyword matching.

[AW2307]

Hey,

just to clarify the logic for unlinked mentions: Document A is shown in the unlinked mentions of document B, if the content of document B contains the exact title of document A.

So it seems to be a clear-cut logic, doesn't it?

Anyway, I think displaying unlinked mentions would be one of those features, which a subset of users find extremely useful, and others wouldn't use. So if implemented, it would be good to make it optional via a global preference.

Personally, I would also like to be able to set a different color for the line connecting mentioned documents, to distinguish them from explicitly linked ones.

[kctekn]

Thanks for the suggestion! I understand you'd like to see unlinked mentions where Document B displays a mention of Document A if Document B's content contains the exact title of Document A. While this logic seems straightforward, we need to consider potential issues, such as common note titles (like "meeting notes" or "research", "index", "readme" etc). These could lead to a cluttered graph with many spurious connections, potentially cluttering the view rather than clarifying it, isn't it?

[AW2307]

Yeah, that's a valid concern for sure. It really depends on each user's needs, I think. For example, all of my notes have unique titles, so I wouldn't encounter this issue.

I wonder if there could be additional filters in the right-hand bar. It's already possible to modify the way orphans are displayed. Perhaps a similar filter could enable showing and hiding of links and unlinked mentions as needed.

[kctekn]

I agree, and we'll consider adding those filters in the future especially after some careful consideration and implementation!