Testing version: iOS 2.1 (12324)
What were you doing: typing an inline note reference
What feature did you use: typing “[[xxx…” to enter an existing note reference.
What happened: My typeahead/search prompt is returning duplicate note references for the same note.
What did you expect to happen: That my search would return a note only one time.
Confirmed that the note is not duplicated in my library. Regardless of which note reference I select, it links to the correct note.
Bear’s autocomplete panel also lists unlinked wiki links since 2.0 to facilitate link insertion. Some people who reported your issues had miswritten wiki link for the target note. In some cases, the difference was very subtle, like a space or a non-breaking character.
If you search for "[[xxx" (the first 3 letters should be enough) in the note list you’ll get all the notes linking the target note. If you don’t have a lot of those, please try to delete all of those links and re-insert them after making sure notes are saved.
i have this same problem, there are a few notes where this occurs and the items are both identical. If i put both wiki links into a note and click on each they both goto the same place. If i update the title of the destination the links both update with the new title.
Unfortunately, I’ve confirmed that all are linked, not unlinked references. Manually reviewing and rectifying is not really feasible because I’m talking about person name references, which could be in the 10s-100s based on my use case.
I’m not even sure how I would attack this even if it was feasible. Seems like I could pull everything in text editor and replace my entire note DB, but then I eliminate my temporal metadata.
I’ll poke around some more, but this is definitely a new issue. Though not sure if it stems from a release, or the major note housekeeping I performed a few weeks ago
Hi everyone, I experienced a similar issue with duplicate entries in the autocomplete list. I managed to resolve it by manually ensuring that all internal note references were wrapped in spaces—so they aren’t immediately followed by any other character like a comma or a period.
Bear Version: Version 2.3.11 (13231)
OS Version: MacOS Monterey 12.7.6 (21H1320)
What were you doing:
I was creating internal note links using the inline reference syntax (i.e., typing [[note]]) within paragraphs of text. In many cases, I followed the closing ]] immediately with punctuation (such as a comma, period, or even a line break) rather than a space.
What feature did you use:
Internal linking via the typeahead autocomplete feature.
What happened:
I noticed that the typeahead autocomplete list displayed duplicate entries for the same note. The duplicates appeared when the closing ]] was immediately followed by any character other than a space. To test this, I searched for all note links in my library and inserted a space after each closing ]], after which the duplicate entries immediately disappeared. This behaviour seems identical to previously reported issues (e.g., “Autocomplete list contains duplicates” from June 2023).
What did you expect to happen:
I expected that the autocomplete list would display each note only once, regardless of the character immediately following the closing brackets. It would be ideal if the parser could handle punctuation and line breaks consistently without creating duplicate suggestions.
I hope these details help in identifying and resolving the issue in a more general and less manual way.
Thanks for this awesome product, I love Bear!