From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:403:4789::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id 4A4nKx6q8WTmbAEAauVa8A:P1 (envelope-from ) for ; Fri, 01 Sep 2023 11:08:46 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:4789::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id 4A4nKx6q8WTmbAEAauVa8A (envelope-from ) for ; Fri, 01 Sep 2023 11:08:46 +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 2C998657B1 for ; Fri, 1 Sep 2023 11:08:46 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=Y5PZvmpH; dmarc=pass (policy=none) header.from=posteo.net; 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" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1693559326; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=IbBuUnoByykZhpYyvc8AiqjHQXGNSyQf0nzoKfI0G2s=; b=GDTrHqZot2uUjG2VpJy7YG5mXYOQw4oZzJp6fz+WNFM/jHpg5SO0IjDwoT/9jqv6wSYPnv L6J9uyPlCrCJuDFQkuSZe0N1shkPrLCkKkITBE+RhbUGxT022a0bSLi0awnQzd5HuYlD+S erYP2i0WJeWsxdqVejPf0+FJGWGrEX/93+/tP8s9RPkZVKg3X1t+YCfDJKk11z/+TcsaYW ai8eRXtL2Wt55sVnbU61bh8LrX2NzDN6VtrvmYOrxpMnPp97L0fUC3enM9tA3d0TxWK8de 0Dv2BBFOJqHkfKZWyT3z4WQLDV+MBZ2wXdnIee+G24RkoboH0S5/FM8Dl4UZkQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=Y5PZvmpH; dmarc=pass (policy=none) header.from=posteo.net; 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" ARC-Seal: i=1; s=key1; d=yhetil.org; t=1693559326; a=rsa-sha256; cv=none; b=hCC0FKleY6Vb7PvbZj/MX5iEIzPHx+oSRd8R0ocJ/KT6fQPWd8q4GDg84rfNFUlpP9vzM5 OTJlNuNAGfrI8g5HjIg5pZqYemE+J/F7h+bCRRNpc5hxwNMkls9EVHBKchdvyjKcwbctX7 ONeR/kyoAx5rW2+d4qIvlTGyWXb48iJD8dZRp7h2jvuYZBd16Qf9zYQXlj6W0n/uNO5vQj fk4pgHgsPcbXYvpkF4Np4uKVI0b+EKGQQ/Dz5tm2lKUcPX9QGCDovgb6/0kox8+lKFGWuj JvtkYc/UkupubbGkSh3ZhvmbLPunVpRN/HHwn7n5JXCO2GjFe/xJcSULtDHECQ== Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qc06y-0007iW-L8; Fri, 01 Sep 2023 05:06:40 -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 1qc04p-0006P3-6x for emacs-orgmode@gnu.org; Fri, 01 Sep 2023 05:04:27 -0400 Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qc04m-0002Pp-Bt for emacs-orgmode@gnu.org; Fri, 01 Sep 2023 05:04:26 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 4DA2324002A for ; Fri, 1 Sep 2023 11:04:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1693559062; bh=al8/x6ytkj3i19klXmCnNcrou3IftgvDr4RbcoCTSGM=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=Y5PZvmpHa6L1kP5ffSjijXRbq3aGxoQ8TXBY+7B7nMcnaA013azg5H5Rnoh8iypqT HX1jEYHBYtYsIjc7NAzObSFL0wR2HKC5j0P6x35Rq98nBYS3CZSJeR8oQbqQP4tM9V L8/avz3J4Rr6tqBW6wGIei32whZOqDRN6BLP5Ia7aaMaqrx9WgdzdNovJJz3/7lG75 gEZtDkjB7myT5NsYknAOMRVXwE5otWoNtqYd4sWP9FA6mdPSqPKZYmz2dgahWsTGmL y2WF+5s6E6Mb1mTIq0ZcXaHqc3lBxDaFgPxRZ5J/etq8JMK5J2K/t/Ung7472JLU5B YJkZRUhzVZVlQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4RcXCJ0lpDz9rxK; Fri, 1 Sep 2023 11:04:11 +0200 (CEST) From: Ihor Radchenko To: Max Nikulin , Bastien , Timothy , Tom Gillespie Cc: Csepp , emacs-orgmode@gnu.org Subject: [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/)]) In-Reply-To: <89434f4f-8aea-23f2-bbfc-3961c18f2154@gmail.com> References: <87il8v2q00.fsf@riseup.net> <89434f4f-8aea-23f2-bbfc-3961c18f2154@gmail.com> Date: Fri, 01 Sep 2023 09:04:48 +0000 Message-ID: <87a5u6tgb3.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham 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-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Scanner: mx1.migadu.com X-Migadu-Spam-Score: -4.51 X-Spam-Score: -4.51 X-Migadu-Queue-Id: 2C998657B1 X-TUID: +imb+b2/Emvs Max Nikulin writes: > However I do not mind to have an easy way to delegate URI from :export > function to the link transcoder of active export backend. Just make the :export function return nil. > Current behavior with with treating link paths as fuzzy search targets > is a kind of compromise. It allows internal search links to be shorter. > One may have e.g. #+name: fig:something code blocks, so not every link > looking as having some "scheme:" prefix should be treated as an external > URI. As a result link types must be enabled explicitly. This is exactly the reason why Org recognizes a closed list of link types and not just "anything looking like protocol:uri". And I am honestly not a big fan - because of the limitations of Elisp regexps, there is actually a hard limit on the number of link types we can support - no more than few hundreds, AFAIR. This is because Elisp regexps cannot be larger than certain length. On the other hand, Org also supports "plain" links without brackets and for such links it does make sense to avoid parsing something like A:B as a link. In theory, we might change the parser to treat anything like foo:bar or or [[foo:bar]] as a link with "foo" protocol and "bar" URI. And introduce [[::fig:something]] to allow explicit internal links. But, despite simplifying the parser, it will certainly be a breaking change. Any thoughts? -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at