A better way to trap title conflicts for wiki-linked drafts?

Mostly, I’ve been pretty good about ensuring the uniqueness of note titles since wiki-links became a thing, using timestamps. Today, I wanted to create a draft titled “apples” and link to it from a shopping list draft. Tapping on the wiki-link I created evoked the “multiple drafts match” response. Fair enough. The prompt offers to open up the quick search, which is useful. But also confuses the issue: quick search apparently doesn’t just return drafts with the search term in the title, so I have to wade through a list of false positives. This is made more difficult by the fact that the width of the quick-search bar truncates longer titles, so I can’t do an accurate eyeball scan of the list to pick out the offending item(s).

Currently, my choices are to:

  • Use the linked keyword/phrase as a search in the drafts list. Similar issues as the quick-search bar (longer titles are truncated, and you can’t limit the search to titles), but at least you can work your way methodically down the list without having to run the search each time…
  • Use a search action. In my case, I used this one by @FlohGro. Tip: the search is case-sensitive, unlike the quick-search tool.

My ideal for this would be to see the quick search tool updated with the option to limit search queries to match against titles only.

Alternatively, it would be useful to have another option in the prompt that appears when a wiki-link returns multiple matches: “run action with wiki-linked text”. That would allow us to run our own choice of an action in this circumstance. Someone else might be able to suggest a better way, but I’d be happy if that prompt button ran an action that was assigned to a specific keyboard shortcut; so, for example, if it ran whatever I’ve assigned to shift+command+h, or whatever— though I know the idea of reserving a keyboard shortcut would be a contentious suggestion for some…


I’m experiencing the same behavior and desire the same results: potential conflicting wikilinks is returning results beyond the title making it a more challenging process to identify the correct draft and eliminating the conflict.

1 Like

Good feedback. Definitely still a lot of rough spots in these features.


That isn’t the worst problem. What the search seems to be doing now is saying that any use of a phrase in a title isn’t accurate enough. E.g. Create a Draft titled “Fred Smith” Try to link to it with a double bracket search, and you get the dialog even if it’s the only one, since it’s matching things like “Other books by Fred Smith” or “What Fred Smith says about it” in the title.

1 Like

I hear you, but there are ways in which that fuzzy matching can be useful. I think the original use case was allowing for titles to be matched in spite of markdown heading syntax, so “# My Title” could be matched by [[My Title]]. I’ve taken advantage of this in the case of placing a timestamp in a title to protect against that title being updated at some point in the future— I know that even if I neglect to update all instances of the references that link to such a title, I’ll be able to link to the draft on the basis of its timestamp regardless of what its title changes to.

There are other ways to handle cascading updates of titles and links, of course. Here’s part of a conversation about it. Admittedly, my own workflow in this case isn’t precise, and depends on my own idiosyncratic way of working with wiki-links— an action that produces a wiki-link based on a timestamp with the rest of the title being outside the double brackets.

Long story short: I’m reasonably sure that the current fuzzy matching of wiki-links is a good thing. But I understand how it might be counter-intuitive and perhaps even undesirable in some cases. Perhaps the wiki-link syntax definition could acquire one more option: [[x:for an exact match]]?