Any `*.md` in text is auto converted to a link
- MarkBind Version: v3.1.1
What did you do? Please include the actual source code causing the issue.
Any text ending with .md (index.md, test.md etc) is auto converted to a hyperlink.
This is an example of a index.md file
What did you expect to happen? It should output the text "This is an example of a index.md file"
What actually happened? Please include the actual, raw output.
index.md is a hyperlink to http://index.md

The raw html code:

Describe the solution you'd like
- [x] Disable fuzzy link (#1779)
- [x] Update documentation to include auto conversion of
http(s)://...texts (#1779) - [ ] Allow users to exclude certain texts from auto converting to links. For example,
http://example.com{no-convert}(Nice to have, p.Low)
Hi @jonahtanjz,
Interesting find! After tracing the code for a bit, I realized that this is actually an added feature of markdown-it's linkify-it. This is enabled in our setup here in core/src/lib/markdown-it
const katex = require('katex');
const hljs = require('highlight.js');
const markdownIt = require('markdown-it')({
html: true,
linkify: true,
});
In fact it turns any URL into a link, so index.com will also be turned into a hyperlink.
index.md is a hyperlink to http://index.md/
Apparently .md is a valid domain as well.
To turn it off we can set linkify: false, but I guess we can keep it on?
Although this is not a bug, I am guessing we should include it in our documentation, under the links section to avoid future confusion.
Thanks @tlylt for investigating this issue.
After tracing the code for a bit, I realized that this is actually an added feature of markdown-it's linkify-it. This is enabled in our setup here in
core/src/lib/markdown-it
To turn it off we can set linkify: false, but I guess we can keep it on?
Ahh I see. I think we can keep it on but is it possible for users to choose not to linkify a text? In case they want to write something like "index.md" as text without it being converted to a hyperlink that leads them somewhere which can be misleading.
Edit: Doesn't seem like there is an easy way to disable linkify for single word/instance. One workaround is to put it in a code block, `index.md`. Maybe include this in the documentation as well :)
Seems like it is possible to set some rules on linkify through markdown-it.

What do you think of disabling fuzzy link so that only text with explicit http(s)://... is converted? Alternatively, we can explore using linkify's schema to define a {no-convert} protocol so that users can explicitly disable conversion for single instance.
What do you think of disabling fuzzy link so that only text with explicit
http(s)://...is converted? Alternatively, we can explore using linkify's schema to define a{no-convert}protocol so that users can explicitly disable conversion for single instance.
On top of defining a rule (which could be difficult to generalize), I think it would still be useful to have a way to disable the link conversion on an individual basis. If not supported natively, it could be possible that we do it in-house with markdown-it-attrs (just an idea) or patch it accordingly.
On the side of author usability, perhaps @damithc can share if there is any use case of auto-link conversion? Personally because it's not part of common mark I think I have never thought of it before.
What do you think of disabling fuzzy link so that only text with explicit http(s)://... is converted?
Disabling fuzzy links is definitely an option.
- seems like Github Markdown is with the non-fuzzy version where index.md won't be converted but http://index.md will.
In case someone needs to deal with this before a solution is decided:
- a quick workaround would be to use code fence
index.mdto disable the link conversion.
Disabling fuzzy links is definitely an option.
- seems like Github Markdown is with the non-fuzzy version where index.md won't be converted but http://index.md will.
This sounds like a reasonable choice . i.e., linkify only if starting with http...
@jonahtanjz after changing to the nonfuzzy version, should we still consider the part where we include a way to escape the link generation for some links that users can specify to exclude(these links do start with http etc)? I think there's no setting in markdown-it to handle such cases.
@jonahtanjz after changing to the nonfuzzy version, should we still consider the part where we include a way to escape the link generation for some links that users can specify to exclude(these links do start with http etc)? I think there's no setting in markdown-it to handle such cases.
Feels like good to have but not worth the effort?. What do you guys think?
Wonder if there is an easier way such as removing the existing rules and define our own validate function? Seems possible with this but I have not tried it out.

Feels like good to have but not worth the effort?. What do you guys think?
If the above is possible then we can go for it. Otherwise, doing it in-house/patching may be too much effort?
Wonder if there is an easier way such as removing the existing rules and define our own validate function? Seems possible with this but I have not tried it out.
There's a bit of logic in markdown-it to handle linkify here. Linkify itself only does the link-text finding and hence if we remove the existing rules provided by markdown-it, we will need to reproduce the logic somewhat to turn it into a link.
Feels like good to have but not worth the effort?. What do you guys think?
I agree it's more like a nice to have and low priority.
There's a bit of logic in markdown-it to handle linkify here. Linkify itself only does the link-text finding and hence if we remove the existing rules provided by markdown-it, we will need to reproduce the logic somewhat to turn it into a link.
I see. Thanks for the explanation.
should we still consider the part where we include a way to escape the link generation for some links that users can specify to exclude(these links do start with http etc)?
Feels like good to have but not worth the effort?
I agree it's more like a nice to have and low priority.
In that case I'll leave this open to whoever is interested :) I've also updated the main issue description to include the solutions that we have discussed.