The role of (anticipating) autocompletion in getting the full benefits of bidirectional linking

This partly about PKM, partly sharing a strategy, and partly a question for folks who understand the details of Obsidian:

The more I use Obsidian, the more I realize how much power there is in autocompletion of bidirectional links, because it introduces linking at the point of composition – not just when searching afterwards. It’s changing the way I think while writing, as I reach for distinctive, complex concepts that I’ve already been developing. This might seem as though it stifles creativity, but I find that it actually helps me to probe deeper, building on thoughts I’ve already had, if only by using the same phrases. If I’m stuck while writing, I just hit [[ and type a few key words, and I’ll often be reminded of a related idea that I can integrate into what I’m writing.

My sense is that the secret to getting the most out of bidirectional linking is anticipating autocompletion. As a result, I’m starting to think a lot more about which titles I use for my notes, so that I can get the most useful hits closest to the top of the autocompletion results window. And for that I would really like to better understand the principles that Obsidian uses for prioritizing autocompletion. For example, words in the name of a folder seem to prioritize the hits significantly, but is that true? Does number of words in a note give it higher priority? What’s currently frustrating is that I get results where there is one word with an “m” plus one word with an “o” and one with a “c” before I get some of my “Filename MOC” notes.

So, my question is: what should I keep in mind – in choosing titles and folder names – so that the notes I want will surface higher/sooner when using autocompletion?

13 Likes

I agree with you on all counts and have the same questions about the “anticipator” autocompletion function (I don’t know what is actually called).

And an observation. If you create a link but do not create the file yet, the “anticipator” still detects it and shows it during autocompletion in future link creation. So you can create several references to this same note title across multiple notes without creating it. This is great for some workflows. But the anticipator allows you to create this link with illegal characters. Fron this I conclude that the anticipator is based on the content of all notes, not on file names. But I want to check with others if my reasoning is valid.

Internal link auto-complete should have illegal character warning

2 Likes

In VSCode they call this ‘IntelliSense’. In other tools they call it content assistance, hinting or completion. It seems this thing has many names :smiley: