[BUG] Trying to fetch references for html links

[danymat]

In zettels that contain links, I get errors like these:

No matching Zettel for reference "https://doi.org/10.1142/S0218488502001648" in 202104020354 Réutiliser une base de données en clair pour réidentifier.md
No matching Zettel for reference "http://arxiv.org/abs/2001.02650" in 202104020424 k-anonymiser revient à appliquer une contrainte sur le jeu de données.md
No matching Zettel for reference "http://arxiv.org/abs/2001.02650" in 202104020428 Algorithme de suppression.md
No matching Zettel for reference "https://www.nasa.gov/centers/goddard/pdf/431367main_PaL%20Brochure.pdf" in 202104060235 Pause and Learn.md
No matching Zettel for reference "https://www.nasa.gov/centers/goddard/pdf/431367main_PaL%20Brochure.pdf" in 202104060245 Les questions à se poser dans la PAL méthode.md
No matching Zettel for reference "https://doi.org/10.5665/sleep.4968" in 202104180404 Dormir peu rend plus susceptible a la grippe.md

[danymat]

I found that this is the code responsible for these errors. I don't understand why you were trying to find references to single [] https://github.com/BasilPH/vizel/blob/2c9ba296a8abbb0bbc645961ee6aa61fa44d1d66/vizel/cli.py#L93-L97

[BasilPH]

Hi @danymat, thank you for taking the time to look into this and creating a PR.

I don't understand why you were trying to find references to single []

As per the README.md, vizel accepts links that either use the [[REFERENCE]] or [LABEL](REFERENCE)format. This is why we allow references that contain a single level of square brackets.

You might for example have a link like this in one of your files: [Questions PAL](Les questions à se poser dans la PAL méthode.md). This is completely valid in markdown.

In that sense, this isn't a bug, as vizel works as documented. I would also like to avoid adding new parameters, like nourls where possible, as it makes vizel more complicated to use.

That being said, I do agree that trying to follow links that start with http is not a good idea, as it clutters the output. I had thought of that, but the solution is non-trivial. For example:

• https://www.nasa.gov/centers/goddard/pdf/431367main_PaL%20Brochure.pdf is definitely a URL.
• www.nasa.gov/centers/goddard/pdf/431367main_PaL%20Brochure.pdf probably a URL as well.
• nasa.gov/centers/goddard/pdf/431367main_PaL%20Brochure.pdf however, is both a valid URL but also a valid local file path. After all, you're not forbidden to have a folder called nasa.gov with contains a couple of subfolders.

You would need to write code, that reliable detects if something is meant to be a URL or a local file path. I think that this is not an easy thing to do and I, therefore, opted to not deal with it all. Do you have an idea how this could be dealt with?

I did add a --quiet flag a while back. It suppresses warnings like the ones mentioned by you. You can see it in #34. I didn't have time to release it yet, but maybe it fixes your problem.