From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:8:6d80::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id YEZzIppIhWC7OgEAgWs5BA (envelope-from ) for ; Sun, 25 Apr 2021 12:46:50 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id CIQUHppIhWDMRwAAB5/wlQ (envelope-from ) for ; Sun, 25 Apr 2021 10:46:50 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id C96E21CC95 for ; Sun, 25 Apr 2021 12:46:49 +0200 (CEST) Received: from localhost ([::1]:37726 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lacHn-0004vr-LA for larch@yhetil.org; Sun, 25 Apr 2021 06:46:47 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:54176) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lacHK-0004vg-Ks for emacs-orgmode@gnu.org; Sun, 25 Apr 2021 06:46:18 -0400 Received: from ciao.gmane.io ([116.202.254.214]:60004) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lacHI-0007eP-Rm for emacs-orgmode@gnu.org; Sun, 25 Apr 2021 06:46:18 -0400 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1lacHH-0000aq-3u for emacs-orgmode@gnu.org; Sun, 25 Apr 2021 12:46:15 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: emacs-orgmode@gnu.org From: Maxim Nikulin Subject: Re: link syntax fixing bug? Date: Sun, 25 Apr 2021 17:46:08 +0700 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 In-Reply-To: Content-Language: en-US Received-SPF: pass client-ip=116.202.254.214; envelope-from=geo-emacs-orgmode@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: 28 X-Spam_score: 2.8 X-Spam_bar: ++ X-Spam_report: (2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FORGED_MUA_MOZILLA=2.309, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, NICE_REPLY_A=-0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1619347609; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=omrFBOiE4EvLhf89Ffp+EqJoh3obya1OkL8+0GafV8A=; b=NbpSaibRnj8rAX037WncBcDMcWhtoZZqHxMufMhb5tkTTmDtNysxhQjmRVu1ivSKn99cze EehVrM+MhvL2ul4itaxXi5EPWWtdK6SrmXvB6eT6nrxWJqx5nHvtllnpJZoi10DeKpGlqy mN+c0P5ZdDe/IdGKMnzkld72X+lMsuuF0G2oYudcUJ4h5QBvPtjwm7aSkvnHQAuubQul9Q tOnkfqjZ70M8TBqumzrKsJvj5gHMYW0PTClaZzfmx/GMI6tJCEMDu/J69cSr28hfDh5S0W kpw9JxE+FCr2W/2L09Qol1HJwlrXO570QgU9MLgvXRFKSKq1vyA/gA+iUlwO9Q== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1619347609; a=rsa-sha256; cv=none; b=pM3pQ5gdMq/njigqaRSRN0PFdbG/NFRsc3arc9S5qQDDX8vlf1GqdrBptZdjZjJw4eN6EO +XaeNjeYomTqrYjIWu+VKfSpSZmhCG0wc9sq+FIu25n6+okONFfiKzNZNEFCL9JKgBWxch 3INWIN8Ky0HkrGzFfx1UFzarNOtcaTeaHyLRisLPZqnkIhR0/8Zxi/yYVnjAWd1x6iU9lg XLW4zBG+6bUQGzXwtCjMh0g1eDlnlPDihQvKcz/NHdaTxnMH9U4sUEA4/UmncnW6SdtwMH 2AgPhaxDFBouqvkL+tY9VEwVeGCSiAPaVw1QNsNlIe+k4CXanuyk9bNk/gGfZQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Migadu-Spam-Score: -0.84 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Migadu-Queue-Id: C96E21CC95 X-Spam-Score: -0.84 X-Migadu-Scanner: scn0.migadu.com X-TUID: hkUw79gp7utg 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[05]\\|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]]