But when I click on a link in the table of contents, some links produce a “multiple drafts found” error.
For example, the target draft is simply named “Services”. The link in the TOC appears as “Services”, but when I click on it, it displays the error and gives me the option to open search. When I do that I get a list of all drafts in all workspaces with the word “Services” anywhere in the title.
It seems that, rather than linking to the specific draft, the link is searching throughout my entire drafts list for the title word rather than for the title.
PS: from reading other posts about backlinks in this forum, it appears that the link actually does perform a search query. If that’s the case, is there a way to either a) search for the exact match (contains “services” but nothing else), or b) limits the search to the current workspace?
Thanks for this idea. I do find it to be better than the earlier version. I’m also playing with a few ideas.
Can I ask why the original link would use a search query rather than linking directly to the specific target draft? It seems like an odd approach.
Also, if I do decide to use the original version of this app, is there a way to query for an exact match (“Title is Services”, rather than “Title contains Services”)?
Better yet, can the query be limited to drafts in the current workspace?
I’m sure Greg can provide a deeper explanation, but I’ll give it a shot from my more limited understanding.
Imagine that you have two drafts titled “Meeting Notes” that you have taken on different days. The day they were created and the title together make a unique identifier, but the title on its own is non-unique. Therefore should you trigger a wiki style link [[Meeting Notes]], you need to be able to return and offer any and all matches to the user. If the match happens to be unique, navigation is direct. If not, you either would need to offer the user a selection, or tell them that it is not unique and to use the link, the user must find the right one and change the title.
By offering the search immediately , this actually helps reduce the number of steps in those circumstances. Conversely the initial search algorithm does lead to the mismatch you highlight.
This explains the why, but you could submit a feature request on the basis of exact matches and then falling back to the search option.
What do you mean by the original version of the app. Are you getting the Drafts app mixed up in some way with actions?
You can certainly code actions for exact matches of titles, but that would not change the behaviour of the wiki style cross links. The functionality of those links is an app feature and there are no application hooks to allow actions to override features or behaviours other than perhaps by overriding keyboard shortcuts.
So, you could create an action where if your cursor is on a wiki link and there are multiple partial matches, it defaults to an exact match. But, while you could have this in the action link, the action row above the keyboard, and tied to a keyboard shortcut, you could not currently have it trigger when you tap on the link. That will trigger the default behaviour.
I do have an action in the ThoughtAsylum - Writing action group called TAD-Process Link that does the following.
Taking the start of any selection as the cursor location, this action will attempt to identify any Markdown or wiki-style cross-link that the cursor is within. The action will then process that link as though it was a link the user had manually activated. If you favour the keyboard as your primary Drafts interaction device, consider creating an action that calls this one and assign it a keyboard shortcut.
Some of the structure of that action could be reused and tailored to the behaviour I described above if you did happen to want to go that route.
The standard search is limited to the current workspace. The search driven by the wiki style cross-links is not limited to current workspace and I would argue that it should not be limited to the current workspace. Some people will undoubtedly rely on the standard behaviour being that it does not. Actions can be constructed so that drafts listings/search that they perform are limited to what would in effect be the current workspace. Note that workspaces are sets of filters and so are not containers of drafts per se - i.e. drafts can appear in multiple workspaces.
Ultimately, the best advice if you want to keep notes in Drafts is to not title drafts to be a compound part of another draft’s title.
For example, rather than notes titled:
# Monday
# Monday - AM
# Monday - PM
Title that first note something like the below to avoid the duplicate search match
# Monday - Primary
# Monday - Main
# Monday:
It might not be a perfect, 100% solution, but it might be a 99% approach that for all practical purposes is good enough.
Yes, I just mistyped. I meant the original version of this action, not this app.
After this discussion, I think I will stay with the original version of the action. I’ll be more specific in naming my notes, and if I occasionally have to open the search, that’s not a problem. I’ll adapt to this structure.
I would argue one point though, but you don’t need to reply. Just a thought.
I anticipate using these actions to create multiple projects, and I’ll probably have at least one “Meeting Notes” note in each project workspace. Even if a wiki-style TOC Meeting Notes link presents me with multiple matches, I would always only want to see the ones that apply to that project. Otherwise, I might as well just use the standard Drafts search function.
But, as I said earlier, I really, really do love these actions. They make Drafts so much more powerful for me. I’m just gonna build a workflow and naming protocols that address these very minor issues.