From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:403:478a::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id 0I7mCvXw9WQFgAEAauVa8A:P1 (envelope-from ) for ; Mon, 04 Sep 2023 17:00:05 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:478a::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id 0I7mCvXw9WQFgAEAauVa8A (envelope-from ) for ; Mon, 04 Sep 2023 17:00:05 +0200 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 E453CF942 for ; Mon, 4 Sep 2023 17:00:04 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=none; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1693839605; 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=/IBwZ5jqREq6F9F+sGb6BdwGLlJNWJibyKOdfAkjp3o=; b=VxC/k5ccHJITDXqhA4hMfudNKQK8CgS7f8sI/Dorw4YYccH61xjKpT4vty4sIirsz/r2Tn ZJ6lSN7OEcJU9aQ2iFU486UvhIFowSdNcXAswajekj29pzYcNHOIx2igswFYDGaUqSg5g6 ZWpb0EVgfUBH7VM8KXmLz8ij/DmCf6I2JKtjn9v95oDyf+ykaiwjTl00laaY4t/MRwUuiD AyU705PzVE4Rgfa8nXqO6dsccAfaMgXzXL7jmdGOnefm5h20pdDY+JK0TV8fY9nHKLkcFC OenEcfj1mq/JTOU0ErLeWetrSI3zYWxIuW/ETWOO4STfgbBuXJyGHj/LFG3xbg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1693839605; a=rsa-sha256; cv=none; b=Re708z/2Jsg7J6IljH0pKEwEKJPnZ7hOoItil23s5bS9IFX+0pp+71KJi9cl+xhuozh/gE GmWfUOjUuZDcEljrzwyUqUlFMkwT7H1quxrjSy+HoYuKqV8Xh2xowSrz3PXCjFNXpGjZV7 S+/ybNac8xXJ4dUnMjaJHvPVqagTxBFulEamZ904i2oXJHFuhH6pKA1x5vrLx/7kzQlmGA ckwsQcQiQbleQQucKK7w4zLI3lzHnmJ4JXItFKZ1NEBz7prjwySPhpamPqvdglNGssI0tI mKYb+hvH8deP2Yx/qZ9RJO7FdtbPtCLa16zE4zPXQhRmRO2M+4ZnDqfMjnCB/g== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=none) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qdB2R-0001IU-Q2; Mon, 04 Sep 2023 10:58:51 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qdB2Q-0001IG-A7 for emacs-orgmode@gnu.org; Mon, 04 Sep 2023 10:58:50 -0400 Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qdB2O-0007La-9K for emacs-orgmode@gnu.org; Mon, 04 Sep 2023 10:58:50 -0400 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1qdB2L-00027A-GV for emacs-orgmode@gnu.org; Mon, 04 Sep 2023 16:58:45 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: emacs-orgmode@gnu.org From: Max Nikulin Subject: Re: [DISCUSSION] May we recognize everything like [[protocol:uri]] as a non-fuzzy link? (was: [BUG] URI handling is overly complicated and nonstandard [9.6.7 (N/A @ /gnu/store/mg7223g8mw90lccp6mm5g6f3mpjk70si-emacs-org-9.6.7/share/emacs/site-lisp/org-9.6.7/)]) Date: Mon, 4 Sep 2023 21:58:32 +0700 Message-ID: References: <87il8v2q00.fsf@riseup.net> <89434f4f-8aea-23f2-bbfc-3961c18f2154@gmail.com> <87a5u6tgb3.fsf@localhost> <87fs3ydv17.fsf@web.de> <871qfirwbx.fsf@localhost> <875y4udqim.fsf@web.de> <871qfhhw7h.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.14.0 Content-Language: en-US, ru-RU In-Reply-To: <871qfhhw7h.fsf@localhost> 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: 13 X-Spam_score: 1.3 X-Spam_bar: + X-Spam_report: (1.3 / 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.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-1.473, 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.29 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-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Scanner: mx0.migadu.com X-Migadu-Spam-Score: -0.71 X-Spam-Score: -0.71 X-Migadu-Queue-Id: E453CF942 X-TUID: DpH6BWy/3Ny0 On 02/09/2023 14:26, Ihor Radchenko wrote: > With my proposal, it would become > > (link :type "sec" :path "spielbeispiel" ...) > > However, "sec" link type will still not be listed in the output > `org-link-types' (not registered). > > Then, ox.el and other link processing code, when encountering a link > type that is not registered, will fall back to searching "fuzzy" link. > > So, export, and following the link should not be affected. I do not see which way it may help in the reported case of complications with URI schemes not enabled by default. What is the purpose of parser changes if links can not be exported or opened? I am unsure if any "PREFIX:" should be recognized as a link type, but there is another possibility on this way: allow users to mark some prefixes as search links, not link types. Taking into account requests to enable more URI schemes by default, requiring to explicitly disable some prefixes may be acceptable compromise. It may be necessary even if fixed set of link types is allowed by default instead of arbitrary prefix. Changes of behavior disturbs a part of users, but strictly adhering backward compatibility means inconvenience for others.