Realizing that I’m wading into what appears to be a controversial subject, I believe this is a bug with the as-is implementation of links in code blocks.
I’m using code blocks to display formatted text with the admonition. And in this rendered text, markdown formatting, including links, is supported. Without third-party plugins, Obsidian searches code blocks for unlinked mentions. You can use both the “backlinks” and “outgoing links” panes to create links for these. However, those panes always show linked mentions as unlinked mentions.
Since, as noted in this request collector ticket, “codeblocks are also used to encapsulate text not just code, like admonition. It makes sense to search in these blocks”, these should also be properly converted to linked mentions.
Whether or not there is some future setting or ability to exclude codeblocks from link searches, at the moment they are included. And the issue reproduces without third-party plugins. So this seems like a bug in the current implementation.
Steps to reproduce
Enable “Outgoing Links” core plugin (optional).
Create a note called “Note A”
Create a note called “Note B”
Add the following contents to “Note B”
Open the “Backlinks” pane for “Note A”. Note the reference to an unlinked mention for “Note A”.
Open the “Outgoing Links” pane for “Note B”. Not the reference to an unlinked mention for “Note A”. (optional)
The linked mention should not appear as an “Unlinked Mention” in either UI. It should appear in “Links”/“Linked Mentions”.
The reference remains in the “Unlinked mentions” section. It does not appear in “Links”/“Linked Mentions”
- Operating system: Windows 10
- Obsidian version: v0.12.10
Note A: Backlinks Screenshot
Note B: Outgoing Links Screenshot
I am not gonna take this as bug report.
As you have found, we haven’t yet decided what to do in the case linked mentions in codeblocks.
I think it’s better if you continue the discussion in that thread or open a feature request.
SIDE NOTE: It is my understanding that admotion has a different syntax for quotataions.
That thread is a whole different beast, so I won’t wade into it. That ticket is about where things should be linked at all, and adding filters to remove links from certain things. That’s not what I’m reporting. Pushing me there just adds noise; it’s pretty lazy triage. Especially after the work I put into making a detailed report and carefully scoping the issue.
This pertains purely to how Obsidian behaves as-is. The current behavior is to link in code blocks (whether people think it should or not)…and that behavior is simply broken. You can put whatever tag on it you want…it won’t change that this is clearly a bug in the existing implementation.
I can’t make you tag or link this in any particular way…but I’m a developer. I know when I’m being swept under the rug because someone just doesn’t want to deal with the thing I found. It doesn’t make the application less broken (or the intended behavior more-clear), which should be shared goal.
Also, the different sytax admonition has is limited in how it can render, has caveats, and is “highly experimental”.
The codeblock syntax works perfectly…it’s just Obsidians linking panes that are broken. So guiding being to use an experimental, partially functional third-party workaround instead of recognizing the issue is…not encouraging.
Oooof, just say the “bug graveyard” tag. That’s extra insulting since this thing is still broken. You literally just pushed it to a place where the brokenness of your stuff isn’t just not prioritized, but doesn’t even get seen!
Responses like this really discourage people from creating thoughtful, detailed reports about issues and behavior, since that effort is unlikely to be rewarded.
I’m going to be much more likely to post lazy, fast reports with less information if I’m just going to be pointed to a place where I can yell into a void and be ignored.
F- … I’m super disappointed.
The issue was already carefully scoped in that thread. Nothing new.
You see it one way. The people in that thread see the complete opposite bug.
The current position is this:
Codeblocks won’t be parsed for linked mentions.
Unlinked mentions are just suggestions so they can be wrong and is up to the user to decide when to link.
I understand users don’t like it.
If you have a different preferred behaviors in mind, open a feature request. It will be the opposite of the linked thread:
They don’t want to see the link button in unlinked mentions within codeblocks. You want to see the link button in unlinked mention and you want linked mentions to pick up text in codeblocks.
The ability to remove those things from places where they are not currently included is a new feature. ALL of those linked tickets are about excluding links from where they are currently included.
Linking on the “Link” button in the “Unlinked Mentions” display, it converting that suggestion into a link, and then not recognizing that link is a bug.
I did obviously read the other ticket since I quoted you. Your previous statements on the matter:
- “It makes sense to seach in these blocks”
- you are “leaving to the user’s discretion what to link”.
Both indicate links are intended and supported. In fact, I just searched the entire forum post for variations and fragments of this statement:
Codeblocks won’t be parsed for linked mentions.
It appears to be a brand new assertion in this post. It also isn’t mentioned in the documentation for outgoing links. So I guess thanks for clarifying…but if this has been stated before, it’s well hidden.
You can win the gold medal in the Olympics doing the acrobatics necessary to claim otherwise…but the application is indicating it does a thing, prompting the user to take an action…and then only partially implements the action they were prompted to take. And that abnormal behavior isn’t documented. That’s a bug.
Since I do want to be constructive, a better way to handle this would be to say something like this:
How Obsidian handles links in codeblocks in links is definitely on our radar, and a subject of much discussion. This behavior clearly isn’t ideal, and at the least the UI here needs improvement. We recognize this, but this is going to go on the back burner until we come up with a clearer vision for how to handle this area.
I like the app so far! And I’m trying to give very thoughtful and detailed feedback…but oof. This definitely doesn’t motivate me to invest in paid products.
And I created a PR to clarify and codify the current expected behavior in the docs:
My previous statements were me advocating for your position in the dispute (again, so far we have received more complains going in the opposite direction). They were not statement of current support in the app.
I know I am not good at support politics. I’ll try to do better in the future.
thanks for the pull request.