I support the previous speaker. I just started with Joplin and I have already stumbled upon this problem. My notes are often programming, but I don’t want to give everything in the code, so I have a link.
I thought it was a problem with Joplin itself, but now I can see it’s Markdown.
It would be lovely if you could turn off this linking machine.
If @laurent is ok with adding that, I can do that in a few minutes.
Actually it IS Joplin and not Markdown. It seems that Joplin's renderer has an option set to turn plain text that is, or just looks like, a URL (or email addess) into a clickable link even though the user has not defined it as such using Markdown.
As I use Joplin more and more I have found that the type of information I am storing in Joplin is increasing and the auto-generation of links, when I don't want links, is becoming rather annoying.
Sure a list can be wrapped in a fenced code block but often I have lists of URLs (or what linkify thinks may be a URL) with other information and they are in tables. That means going to each "URL" in each cell and adding <span> tags or using inline-code to "neuter" linkify. I am starting to find that this is, as they say, a PITA.
I could use a style sheet for these notes to correct the formatting but the supposed links would still be live and @fhellwig makes an excellent point about Markdown's raison d'etre.
This thread has been going on for over a month now. In light of @tessus' comment is there any chance of having a "ruling" on this? 
I’m not sure we need to change something? I think it’s pretty standard to convert links to clickable ones when rendering, and to prevent this behaviour it’s always possible to escape using \.
In the end if we change the default behaviour, it might solve some issues, but also create new ones, so I’d rather leave it as it is.
I only meant I’d add another entry in the plugin section where people can turn this off. I’m not saying to change the current default behavior. I would not be ok with that.
Or I can also put it in the Note section: Disable linkify
Yes but as always I'm not keen on adding yet more options. For example, look at Discourse or StackExchange which are used by millions of people: there's no per-user options to customise the Markdown. There could be but it's not really needed because it's mostly fine for most people as it is.
Options aren't free, the cost is making the codebase more and more complex over time and making it harder to make improvements. Even now, for me the Markdown renderer is getting too complex and I'd rather remove options than add more to it.
If I have read the above correctly, what therefore is the purpose of having the ability to create plugins?
Isn't plugin functionality there for those situations where "mostly fine for most people" isn't quite good enough and a little enhancement could help?
BTW, when posting this I am becoming very aware of Sayre's law on my part, "In any dispute the intensity of feeling is inversely proportional to the value of the stakes at issue." 
I don't have a personal stake in this, since I build my own Joplin with a few tweaks anyway, so should I ever need this, I just add it.
However, if this is a major pain point for a lot of people, I don't see a reason why this shouldn't be added. It's a simple enough change and there won't be any adverse effects in the future.
IMO StackExchange is not a good example. I find their formatting abysmal. I think you still can't format code in replies (only in answers).
This is not about customising Markdown, quite the reverse. It's to prevent where "linkify" in markdown-it is set to render a piece of text making it behave as a link even though there is NO Markdown code to instruct it to actually do so. I am now having to store potential malware URLs in text files attached to notes. It is unsafe to have them in a note because Joplin will make the URL "live" even though I have not set it to do so using Markdown (and now I cannot search for an identified "bad" domain because it is in an attachment).
Yes, it's edge-case, but having a plug-in toggle to set linkify=false, appears hardly adding major complexity to the code-base. Once more I am drawn to highlighting @fhellwig's post,
But there is, in my opinion, a larger philosophical issue here… we all love Markdown for exactly the reasons we, relatively speaking, dislike Word and the like: It gets out of your way and lets you create content representing exactly what you want and nothing more. (No magic, don’t do me any favors, etc.)
If anything there should just be a plugin that switches linkify on.
I have had a look at build.md and I can honestly say that I am none the wiser 
when it comes to how to build my own version of Joplin without this auto-link / "Joplin knows best" feature.
EDIT:
I'll admit that I am getting a bit "intense" about this deviation from being a Markdown-based app but of course it is not going to stop me using and supporting Joplin.
@dpoulton, what case in particular can be a problem with linkify? Is it because it incorrectly identify some text as urls? In which case, perhaps we can fix the logic.
I think it might help to give a number of concrete examples and see if there's a way to improve rendering of links.
It's not that sometimes linkify gets it wrong, it's that it does it at all.
Paste this into a note
(1)
| Script Name | Function |
| --- | --- |
| script1.py | Function description |
| script2.pl | Function description |
| script3.sh | Function description |
| script4.bat | Function description |
## Instructions
Enter the username in the format **username@domain.com**
Use the following actions in the game, st.MK, cr.MP, j.HK
*(this is a real example - see above)*
(2)
| URL | Warning |
| --- | --- |
| track.example.com | Tracker |
| ads.example.com | Ads |
| kittenpics.example.com | Malware |
(1) Automatically makes unwanted, meaningless links and upsets formatting.
(2) Automatically makes unwanted and potentially dangerous links.
until you enter http: //, https: // or www, the machine should not create a link at all. And that will be bad in some cases.
For example, I often use periods in passwords. So often in the notes in which I included these passwords as a link.
In the lists of files needed for the project: file.py file.md file.au and others.
In programming languages //comments.99 //558889.badnumber (this is a link to nothing)
it works wrong.in my opinion
who needs a link to //localhost
Thanks for clarifying. I mean I would be fine to change the linkify logic so that it only handles text that start with a valid URL scheme (http://, file://, etc). That would fix all the cases above.
It would however break the case where a user expects a link for scheme-less URL but I think it's acceptable as there would still be several ways to render a link, either by adding a valid scheme or by using the link syntax.
So to sum up it would work like this:
Current behaviour
https://example.com => https://example.com
file://C:\AUTOEXEC.BAT => file://AUTOEXEC.BAT
example.com => example.com
oo.ps => oo.ps
test@example.com => test@example.com
Proposed behaviour
https://example.com => https://example.com
file://C:\AUTOEXEC.BAT => file://C:\AUTOEXEC.BAT
example.com => example.comoo.ps => oo.pstest@example.com => test@example.comI also suggest not auto-linking email addresses. How does that sound?
That sounds great. Thanks for listening.
That does seem like a lot of work when all that was being suggested was to have a plugin that enables a user who does not need it to set linkify to false in the renderer. Just like switching on/off typographer, fountain, mermaid, footnotes, TOC etc.
Regardless, I appreciate that this is your project and so should follow your vision for its development. I promise that I will not go on about this any more
I think you might be under-estimating the added complexity of adding options Short term, it's indeed easy to add an option. Long term, having plenty of options that interact with each others and that need to be maintained gets more and more difficult.
In general I also prefer if there are as few options as possible that affects the markdown rendering. Each new option means it will be rendered one way in Joplin and a different way somewhere else. At least if Joplin has a fixed default rendering, it's easier to make sense of the Markdown when it's exported to other software programs.
The above is just a proposition though, and I'd be interested to know what others have to say about it, whether they could be drawbacks or unforeseen issues.
Thanks for chiming in Laurent.
Personally, I would not want auto-link generation of any kind as I don't feel any Markdown app should be creating extra markup on my behalf.
Of course, I do understand that Pandora's box has already been opened since many apps have already implemented this functionality (and even then, with inconsistencies on what exactly gets turned into a link).
At least for my particular use case, I would be happy with your proposed solution.
I think following GFM's autolink rule is another option when it comes to choosing the "default rendering" mode of Joplin, rather than creating a new set of linkifying rules from scratch. By the way, GFM doesn't linkify oo.ps and example.com but it coverts email addresses to links: try it in BabelMark.
Personally, I think it is logically more consistent to provide users with the option for turning the linkifier off, considering the fact that Joplin's Markdown guide prescribes Joplin follows the CommonMark spec with additional features added via plugins. (CommonMark does not auto-linkify any URIs/URLs unless they are surrounded by angular brackets.)
However, I understand if you decide not to create an additional option for that. After all, once the new plugin system is introduced, one will be able to create a customized plugin overwriting Joplin's default linkify rule, and I can wait until then.
I agree with what alexxnz wrote.
I will also be grateful if the changes proposed by Laurent will be introduced in the next version.
Thank you
I've added a spec there:
Please have look at it and let me know if you have any suggestions or comments.