RFC: Disable automatic link creation?

It's not that sometimes linkify gets it wrong, it's that it does it at all.

Examples

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.

Some user examples are in this thread at posts 8, 20 and 21

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

Proposed behaviour

I also suggest not auto-linking email addresses. How does that sound?

@laurent

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 :slight_smile:

I think you might be under-estimating the added complexity of adding options :slight_smile: 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.

3 Likes

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.

2 Likes

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.

I had this problem as well... I just downloaded and started using Joplin today for my Python online class and when I was taking notes everything I wrote that ends in ".py" is being automatically shown as a link when I don't really intend it to be a link, they are just python filenames from my notes. This feature is rather really annoying(at least on my usecase), an option to just toggle it on/off would be perfect as others have already pointed out.

Yes I intend to review that again. At the very least it shouldn't linkify filenames like "something.py".

If you build Joplin yourself, here's a commit that you can use for such a toggle....

The commit hash will change since I force-push this branch a lot....

1 Like

There's a second attempt at improving link detection, based on the feedback from the previous attempt. I think it's a better compromise than the previous approach and yes, there would now be a linkify option as that seems to be necessary.

Feedback is welcome!

1 Like

I suppose that is version 1.5.4 of Joplin this new linkify option still to come, right ?

Just having the option to toggle off linkify and would be good enough for me. The additional tightening up of linkify looks like it could help those that are looking for somewhere sensible between off and how it currently works.

1 Like

Tested in 1.5.7 and it works well, with the caveat that in WYSIWYG mode you have to switch to another note and back before the link is actually hyperlinked/clickable

As far as I can tell, the latest iOS app (10.4.1) does still behave like Joplin desktop did before version 1.4
Thought this as a reminder to the iOS developer. I think it is important that changes like this (not just UI mods) are picked up by mobile apps asap (if possible).

@msbentley : correct, another note, or to the MD editor and back. Would be nice if this got fixed too.

Not sure what that means.

All apps pretty much use the same code base, so Laurent is the dev for all apps.

Not sure either, my excuses.