@AWolf81 ping

@ZeroX-DG Sorry, for not responding. I've thought your requested changes are easy to fix but there is a new issue once I've removed the # from the link and I'm not sure how to fix it.

Codemirror is changing the link handling with-out the #. In the following screenshot you can see the difference.

The first link is as we'd like to have it :tag:1st and the second is the old one with the hash :tag:#1st. You can see at the editor highlighting that Codemirror does something different - blue text vs red.
In the html markup there are several spans for the url instead of one.

I need to do more debugging for this. Do you have an idea what could cause this? An easy fix would be to use the # in tag links but I'll try to find a solution with the consistent tag-links as discussed before.

CodeMirror used to do weird things in the markdown syntax. For example:

• Random words underlined #1007

So I think it's CodeMirror Markdown parsing issue. Currently Boostnote used its' own CodeMirror mode, so we can fix this by overriding the rule in mode I think. But I'm not quite sure how to do it yet. I'll see if I can find out a way to fix this but in the mean time u are welcome to help me investigate on it.
https://github.com/BoostIO/Boostnote/blob/master/extra_scripts/codemirror/mode/bfm/bfm.js

@ZeroX-DG OK, I've found the location of the problem. It's inside codemirror/mode/gfm.js in the regex

var urlRE = /^((?:(?:aaas?|about|acap|adiumxtra|af[ps]|aim|apt|attachment|aw|beshare|bitcoin|bolo|callto|cap|chrome(?:-extension)?|cid|coap|com-eventbrite-attendee|content|crid|cvs|data|dav|dict|dlna-(?:playcontainer|playsingle)|dns|doi|dtn|dvb|ed2k|facetime|feed|file|finger|fish|ftp|geo|gg|git|gizmoproject|go|gopher|gtalk|h323|hcp|https?|iax|icap|icon|im|imap|info|ipn|ipp|irc[6s]?|iris(?:\.beep|\.lwz|\.xpc|\.xpcs)?|itms|jar|javascript|jms|keyparc|lastfm|ldaps?|magnet|mailto|maps|market|message|mid|mms|ms-help|msnim|msrps?|mtqp|mumble|mupdate|mvn|news|nfs|nih?|nntp|notes|oid|opaquelocktoken|palm|paparazzi|platform|pop|pres|proxy|psyc|query|res(?:ource)?|rmi|rsync|rtmp|rtsp|secondlife|service|session|sftp|sgn|shttp|sieve|sips?|skype|sm[bs]|snmp|soap\.beeps?|soldat|spotify|ssh|steam|svn|tag|teamspeak|tel(?:net)?|tftp|things|thismessage|tip|tn3270|tv|udp|unreal|urn|ut2004|vemmi|ventrilo|view-source|webcal|wss?|wtai|wyciwyg|xcon(?:-userid)?|xfire|xmlrpc\.beeps?|xmpp|xri|ymsgr|z39\.50[rs]?):(?:\/{1,3}|[a-z0-9%])|www\d{0,3}[.]|[a-z0-9.\-]+[.][a-z]{2,4}\/)(?:[^\s()<>]|\([^\s()<>]*\))+(?:\([^\s()<>]*\)|[^\s`*!()\[\]{};:'".,<>?«»“”‘’]))/i

There is a tag matcher that's causing the problem. I have to check where I can override the regex rule in bfm.js or should we change the tag link syntax back to :tag:#tagname? Because changing the regex would limit the user from using tag inside urls.

The other issue with feedback is not happening.

During testing, I've found another issue: If your search term is matching tag then the link handling is not working as expected.

It's tempting to switch back to the # syntax but that will conflict with @Rokt33r idea. We probably need to fix this instead of using a workaround.

Yes, you're right. We should try to fix it.

I've changed the regex URL_re in gfm by removing the tag then it was working. I'll check later what link it was planned to match because I think it shouldn't match:
tag:something

Do you know how I can overwrite or replace the gfm inside the bfm mode?

That's a hard problem, I'm still investigating how we can do that. I wonder if we create our custom gfm mode file and include it like bfm mode, would it work?

@ZeroX-DG Yes, that was a hard one.
But I think it's OK now. Please have a look.

I've added gfm with a modified regex to Boostnote. I removed the tag from urlRe. Do you know what link the tag should match? Is it tag://something? I haven't found anything about it in my Google search - so I can't improve the Regex.

I've also fixed the other issue with the search term hitting a link. Just highlighting of the link looks a bit off but the click handler is working as expected. (I also added this to normal link handler - code duplication is OK here as it's only used in two locations)
Should I check the highlighting as well or is it OK as it is?

The highlighting works flawless on my side. I think this looks cool. Can you show me the highlighting bug on your side @AWolf81 ?

BTW I have no idea with tag in URL is for 😄

@ZeroX-DG I wouldn't say it's a bug. I just think this could be improved.
Hovering over the search term tag just shows ctrl+click tooltip but no link highlighting displayed (see first screenshot below). Or hovering over the other parts : or :1st will just highlight that part of the link instead of the complete link.

Hovered search term screenshot:

And here with-out a search term and correct light blue highlighting:

I'm not sure if I'm a bit too critical here but fixing this could be a bit tricky as the yellow highlighting is conflicting the hover effect and that there a multiple spans involved. I think that could be also fixed later as the click handling is working as expected.

@AWolf81 I see. I think it's gonna be very tricky to fix the highlighting for the search term. Since it's not a major issue, I don't think with should hold this PR and fix it. I think for now this PR looks great, I'll approve it and get it merge first. Then we can find a way to deal with that search term highlighting stuff.

A possible solution for that issue is by using markText to create our own link element
https://codemirror.net/doc/manual.html#markText

Nice fix! This works properly for both internal links (to different views) and external links.

However, there does still seem to be an issue with this not working for references within a single note. For example in the TOC: