Link references escape html in v0.25.6

[stefanfritsch]

Describe the bug

The link reference definitions have suddenly started using html escaping for slashes which breaks links.

E.g.

I want to link to [[another page]] but this produces the reference below.

[//begin]
[another page]: ..%2F..%2Fanother%20page.md "another page"
[//end]

This is broken in v0.25.6. Downgrading to v0.25.5 fixes the issue.

I also don't see why #1311 decided to replace the (valid in markdown) spaces in angel brackets with the less readable %20 but unlike replacing the path separators (i.e. /) with %2F this doesn't break the links.

Small Reproducible Example

No response

Steps to Reproduce the Bug or Issue

1. Create some page
2. Create a page in a different directory linking to the first
3. Update the link reference definition

Expected behavior

The definition should look like this:

[//begin]
[another page]: ../../another%20page.md "another page"
[//end]

or this

[//begin]
[another page]: <../../another page.md> "another page"
[//end]

Screenshots or Videos

No response

Operating System Version

Windows

Visual Studio Code Version

1.85.1

Additional context

Foam v0.25.6, downgrade to v0.25.5 fixes issue

[riccardoferretti]

Seems related to #1311 - cc @MABruni

[MABruni]

Thank you for the feedback @stefanfritsch!

I've opened #1322, that one should fix what you describe. Encoding targets only the filename now, this leaves path separators unchanged. Also, I agree with you that spaces make it more readable, I changed the code to preserve spaces in filenames.

[stefanfritsch]

Thank you very much!

I just ran the janitor in v0.25.7 across a repo with a few thousand files and everything looks great.

One question, if you're still reading this: Is it working as designed that I can no longer follow wikilinks but instead have to use alt+click to jump to the definition and then alt+click to follow that to the destination?

[riccardoferretti]

This is due to VS Code and not Foam.
They changed the navigation behavior a few versions back, I haven't been able to find a workaround to navigate directly to the resource