Greedy Filtering On linkedFrom Queries

[Mike Higginbottom]

I have three notes created, one for each of three hills in the English Lake District called Raise, High Raise High Street and High Street respectively. They contain the following front matter:

Raise.md contains:

---
location: [54.5477897,-3.0162845]
---

and HighStreet.md contains:

---
location: [54.49145423971695,-2.864866454252744]
---

and HighRaiseHighStreet.md contains:

---
location: [54.51300908690752,-2.8530245586249996]
---

With Interactive Map View Filters set to linkedFrom: and View set to Follow active note if I open any of these three notes it shows a single marker at the expected location.

However, if I create a note test.md containing a link to HighRaiseHighStreet.md as follows:

[[HighRaiseHighStreet]]

the Interactive Map View shows three markers. One for Raise, one for High Street and one for High Raise High Street when it should only show a single marker for High Raise High Street.

My guess is that the code is filtering the list of files and matching all three notes to the search string HighRaiseHighStreet, possibly at line 124 of query.ts:

                if (
                    linksFrom?.links?.some(
                        (linkCache) =>
                            linkCache.link
                                .toLowerCase()
                                .includes(marker.file.basename.toLowerCase()) ||
                            linkCache.displayText
                                .toLowerCase()
                                .includes(marker.file.basename.toLowerCase())
                    )

where it seems to be using includes rather than some form of exact match. This may be by design as a way to catch close matches but I suspect functionality would be improved for most use cases by matching exactly what the user requests.

[esm7]

Indeed this is part of an attempt to catch close matches, but I agree this should not be the case in the linkedFrom query. This one should only include exact matches. Will fix.

[esm7]

Fixed in 3.0.2.