zim-wiki team mailing list archive

[Raphael Hertzog <hertzog@xxxxxxxxxx>]

On Tue, 15 Dec 2020, Jaap Karssenberg wrote:
> Found it - this is a regression when I made the URL parser more Markdown /
> GitHub compliant (recognizing closing parenthesis etc.) based on
> https://github.github.com/gfm/#autolinks-extension-
> 
> The parser now recognizes links starting with "www." as a special case
> without the "http://"; in front. However in a later parsing step these are
> misqualified as page links.
> 
> This can be fixed two ways (1) step recognizing "www." links unless they
> start with "http://"; or (2) make sure these links are properly recognized
> as URL links instead of page links. For future compatibility with Markdown
> I prefer solution (2).
> 
> Any thoughts ?

I was about to say that I'm fine with (2) but in fact I have another
somewhat related problem... consider this input:

[[mid:CA+TmwMHj9wyWFWjS+JVP4506wPp4b693NSK88JO=+Y3F=JudeA@xxxxxxxxxxxxxx|Jaap Karssenberg]]

Up to now, I could paste this and after a CTRL+R I would have the desired
link. Now when I paste it, I get a link on the text "mid:CA...@xxxxxxxxxxxxxx"
and the reload doesn't change anything, I still see the markup. I first
have to right click to remove the link before it will work.

So I'm not sure that I like them very much unless you have some logic to
disable them:
- detect when you are in a manual link construct?
- maybe have a "Paste as wiki markup" ?

Cheers,

PS: Yes I have a special url handler for the "mid" prefix, launching my
email client on the linked email.
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog <hertzog@xxxxxxxxxx>
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋    The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄⠀⠀⠀⠀   Debian Long Term Support: https://deb.li/LTS