From: Maxim Nikulin <firstname.lastname@example.org> To: email@example.com Subject: Re: link syntax fixing bug? Date: Sun, 25 Apr 2021 17:46:08 +0700 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <CAJcAo8vaUtzzEC+EhnDssOa8Zw6KW=54zg0qyN3WsxH8DGs70A@mail.gmail.com> On 21/03/2021 05:46, Samuel Wales wrote: > the issue is that when i click on google, the space before "hi" does > not show up in the earch box. ergo, different results. > > *** should be orig > [[http://www.google.com/search?q=%7E%22retroactive%20whatever%22%20%22hi%22][retro > original]] > *** should be fixed, is not? > [[http://www.google.com/search?q=~"retroactive whatever" "hi"][retro > original]] Reading Kyle's response, I have realized that you might have unsafe URL handler. I hope, I am wrong. To factor out some excessively smart JS, I tried firefox 'http:/127.0.0.1/search?q=~"retroactive whatever" "hi"' and I got expected result in the URL bar. With the following test script "fake-browser" #!/bin/sh exec kdialog --title "Fake Browser" --msgbox "Args $#: '$*'" and a some customization: '(browse-url-browser-function (quote browse-url-generic)) '(browse-url-generic-program "fake-browser") I did not get any white space problem for the following link [[http:/127.0.0.1/search?q=~"retroactive whatever" "hi"][retro-original]] So neither passing URL to handler nor handling URL by firefox cause a problem. However protecting spaces in URLs from `org-fill-paragraph' function was mentioned in mail list archive as one of the reasons to introduce second pass of percent encoding. Double percent encoding is clearly a problem since there is no way to reliably guess whether second pass was applied or not. My impression, it were not a problem if just "offensive" for org symbols "][ \" would be replaced by percent-encoded equivalent in URLs. Maybe I just missed cases when mixing percent-encoded and unicode characters leads to some problem, so I believe it is safe. My hypotesis is that replacing just "[", "]", and "\" to percent encoded equivalent in any URL does not cause any issue, web-servers are able to decode them (selective encoding, not second pass for whole URL). Maybe file links on windows is an exception. My opinion is that `org-lint' gives false positives for URLs with percent encoded characters. They are rather wide spread e.g. in search queries. > *** [[https://orgmode.org/Changes.html][Org mode for Emacs – Release notes]] > The following function will help switching your links to the new syntax: > > (defun org-update-link-syntax (&optional no-query) ... > (while (re-search-forward "\\[\\[[^]]*?%\\(?:2\\|5[BD]\\)" nil t) I believe, the logic at least for space symbol (%20) should be more sophisticated. Maybe decoding of URLs with "%20" should be performed only if decoded URL still contains percent-encoded characters. Maybe decoding should be prevented if any of characters mandatory for percent encoding ("?/", etc) is present besides percent-encoded sequences. Maybe the only way is interactive comparison of original and decoded URL. I do not think that particular example you provided http://www.google.com/search?q=%7E%22retroactive%20whatever%22%20%22hi%22 needs decoding. It is not human friendly but it is more safe and quite wide spread. On the other hand, decoded variant should not lead to any problem as well unless something is misconfigured [[http://www.google.com/search?q=~"retroactive whatever" "hi"][retro original]]
prev parent reply other threads:[~2021-04-25 10:46 UTC|newest] Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-03-20 22:46 Samuel Wales 2021-04-17 19:27 ` Kyle Meyer 2021-04-25 10:46 ` Maxim Nikulin [this message]
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: https://www.orgmode.org/ * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --email@example.com' \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: link syntax fixing bug?' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox: https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).