Closed idbrii closed 4 years ago
Describe the bug :h s/\0 produces a response that includes a forward slash instead of url-encoding it to %2F.
:h s/\0
%2F
Not sure if there are other cases that fail to url-encode the forward slash, but change.txt has lots of examples that include it.
I guess you may want to re-use vimhelp.org's logic for url encoding to avoid similar problems? Maybe it's standard?
To Reproduce
Example:
https://www.reddit.com/r/vim/comments/jk3nw1/wait_for_it_this_is_what_we_can_do_with_vim/gaht6k5/?context=1
Actual behavior https://vimhelp.org/change.txt.html#s/%5C0
Expected behavior https://vimhelp.org/change.txt.html#s%2F%5C0
The actual link takes you to the top of the help page. The expected link takes you to the specific help entry.
The bot already encodes the URL's, but I think urllib's default behaviour is to consider / as safe. Should be an easy fix
urllib
/
Describe the bug
:h s/\0
produces a response that includes a forward slash instead of url-encoding it to%2F
.Not sure if there are other cases that fail to url-encode the forward slash, but change.txt has lots of examples that include it.
I guess you may want to re-use vimhelp.org's logic for url encoding to avoid similar problems? Maybe it's standard?
To Reproduce
Example:
https://www.reddit.com/r/vim/comments/jk3nw1/wait_for_it_this_is_what_we_can_do_with_vim/gaht6k5/?context=1
Actual behavior https://vimhelp.org/change.txt.html#s/%5C0
Expected behavior https://vimhelp.org/change.txt.html#s%2F%5C0
The actual link takes you to the top of the help page. The expected link takes you to the specific help entry.