Dynalist internal links should be matched when search query matches the title of the item that they link to

Steps to reproduce

Create an bullet. Ex: Item
Get the link to this bullet
Paste the link on another bullet, adding a tag at the end. Ex: [pasted link to bullet] #tag
Get the link to this bullet
Paste the link on another bullet

Expected result

A formatted link that shows: “Item #tag

Actual result

A formatted link that shows: “[item url] #tag

Environment

Windows 10
Chrome

Solution: you can rename it at will with this structure

[name you want]@(horrible-big-link)
without the @

1 Like

I’ll do it. Just wanted to register.

1 Like

Thanks for submitting this!

However, I don’t believe this is a bug. It might be confusing because the “prettify” effect, i.e. Dynalist automatically fetches the item title for you. If you check out the plain text version, it’s just a plain link.

There’s another bug: Markdown is not correctly rendered when there’s one named link inside another. I believe that’s not the case you’re talking about?

That’s a problem too. I believe the “prettify” effect is related to another issue too: Make internal links searchable by its referred content

What about you use [[ to insert the link rather than manually pasting it?

That way by default a named link rather than unnamed link is inserted.

I still think both of these are expected behaviors, to be honest. The link itself doesn’t have much meaning, so we showed the item title in its place hoping to bring more clarity. Doesn’t mean the text is actually there. It’s just like if you search for “Today”, you won’t find !(2017-05-13), as “Today” is just a friendly way to display it. It’s not what it actually is.

1 Like

I think it’s about efficiency.

  • Doing things faster: most of the time I have multiple windows open. It’s easier to copy/paste the link.

  • Keeping the name congruency: by using pasted links, I don’t have to worry if the text at the linked bullet is altered. With links, I always get the truth.

  • Smart search: the search should find what the user intends to find. No one would query URL characters. Applying this to your excellent date example: a smart search should find both the friendly way to display and the text. That’s a good search.

I’m had to stop using links because after gathering and structuring the information, I would miss details at the analysis phase, which is search intensive. (Work with litigation)

you still can rename the link and its searchable so.

That would be a Smart Search feature rather than a bug. What I’m insisting here is that the plain text search is doing what it should, so it shouldn’t be considered a bug.

We can move the thread over the the Features category.

Oh, sorry. I understood it now.

It would be better to move the topic. Thanks

Moved it, sorry for the late reply!

I changed the title, feel free to change it if you want to improve it.

Your title is better. This feature is naturally confusing :smile:

1 Like