Skip to content

Markdown links with whitespace can no longer be resolved in Wiki #10223

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
3 of 7 tasks
proton-ab opened this issue Feb 10, 2020 · 7 comments · Fixed by #10611
Closed
3 of 7 tasks

Markdown links with whitespace can no longer be resolved in Wiki #10223

proton-ab opened this issue Feb 10, 2020 · 7 comments · Fixed by #10611
Labels
issue/not-a-bug The reported issue is the intended behavior or the problem is not inside Gitea

Comments

@proton-ab
Copy link
Contributor

proton-ab commented Feb 10, 2020

  • Gitea version (or commit ref): 1.11.0
  • Git version: -
  • Operating system: -
  • Database (use [x]):
    • PostgreSQL
    • MySQL
    • MSSQL
    • SQLite
  • Can you reproduce the bug at https://try.gitea.io:
    • Yes (provide example URL)
    • No
    • Not relevant
  • Log gist: -

Description

Markdown links to other pages in wiki are no longer resolved if they have whitespace in them.
https://try.gitea.io/3red3x/wikitest/wiki/Home
https://try.gitea.io/3red3x/wikitest/wiki/Development-database-snapshot

Screenshots

Raw link:
chrome_2020-02-10_22-59-45
On Gitea 1.10.2:
chrome_2020-02-10_22-59-34
On Gitea 1.11.0:
firefox_2020-02-10_23-00-04

@lafriks lafriks added this to the 1.11.1 milestone Feb 10, 2020
@lafriks lafriks added type/bug issue/regression Indicates a previously functioning feature or behavior that has broken or regressed after a change labels Feb 10, 2020
@heliomcp
Copy link

I have an identical ticket #10156

In my example I only use 2 markdown pages inside a directory with a space in the name and if we use the link between the to pages Gitea change the stace (%20) to signal +

@proton-ab
Copy link
Contributor Author

That's a different issue - in your case there's improper entities handling when constructing link, but the link does get parsed. This issue tracks case where markdown links are not parsed and constructed at all when they contain space and are not an URL but relative name.

@mrsdizzie
Copy link
Member

FWIW this is intentional as it is not allowed in the commonmark spec:

https://spec.commonmark.org/0.29/#link-destination

a sequence of zero or more characters between an opening < and a closing > that contains no line breaks or unescaped < or > characters, or

a nonempty sequence of characters that does not start with <, does not include ASCII space or control characters, and includes parentheses only if (a) they are backslash-escaped or (b) they are part of a balanced pair of unescaped parentheses. (Implementations may impose limits on parentheses nesting to avoid performance issues, but at least three levels of nesting should be supported.)

And we now use a new markdown library that follows that spec (as a feature).

You can find similar issues for other projects that follow commonmark (or use a library that does). So it's a regression in the sense it used to work when we used a library that didn't follow a standard, but if part of the goal of switching is to follow a standard then I suppose it is intentional now and a breaking change.

As per the spec, you can keep the page names with spaces you just need to enclose the links in <> brackets:

https://spec.commonmark.org/0.29/#example-486

So in your example it would need to look like:

[Development database snapshot](<Development database snapshot>)

@techknowlogick techknowlogick modified the milestones: 1.11.1, 1.11.2 Feb 17, 2020
@guillep2k
Copy link
Member

Related: #10291

@mrsdizzie
Copy link
Member

This could probably be closed as a breaking change with switching to a markdown parser that follows a particular spec (which we listed as a reason for switching to it). Comment above is the new "right" way to use short links with spaces according to commonmark

@proton-ab
Copy link
Contributor Author

Agreed, should be documented as breaking change however.

@guillep2k guillep2k added issue/not-a-bug The reported issue is the intended behavior or the problem is not inside Gitea and removed type/bug issue/regression Indicates a previously functioning feature or behavior that has broken or regressed after a change labels Mar 5, 2020
@guillep2k guillep2k removed this from the 1.11.2 milestone Mar 5, 2020
@guillep2k
Copy link
Member

Closing as this was the expected behavior. Docs will be updated to clarify the case in #10223.

@go-gitea go-gitea locked and limited conversation to collaborators Nov 24, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
issue/not-a-bug The reported issue is the intended behavior or the problem is not inside Gitea
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants