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 GM5xESzo8mQsXQEAauVa8A:P1 (envelope-from ) for ; Sat, 02 Sep 2023 09:45:48 +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 GM5xESzo8mQsXQEAauVa8A (envelope-from ) for ; Sat, 02 Sep 2023 09:45:48 +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 068899E02 for ; Sat, 2 Sep 2023 09:45:48 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=ZqOeLykq; 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=1693640748; 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=N1+XEfRW5WBuiMAFqdOFio25JJ35v03DKeTztqL5wsE=; b=K6yjGlmMe9Ghpq14kdoTfPAmHF+D1eSBXgDNPbB8TV/P24T/8F6zsaQOZR+SdTAe86pFyf TBEWHRWFd7DFRvs3eilaOKZ2AYDhV86B1fH+OVUSOE50LM8h/TxcACc72i+z2EpU214V10 ul3cV7Oi20RAu2D/LXsoKoc+PH4wdRgbOo4z/rBDpbSJOtyyqlB3zYtsb1ox/3yuSoUHG3 xD4tnr0KTyTH3G61/rlEWk0f066g+81bfP0biOFIWTZXEpfwNFeH8+arxLbjp/35amyT0f L39/Zusw/zDoSOP5dWAdugaGzivkNHgdpG/Var9u6iIwzlFktg4Bb+qKimVDBQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1693640748; a=rsa-sha256; cv=none; b=UPb8hdZNpnhinWs2GiAvZIdi73MFcAt1J7Qwdv10/TMnt97cXm6wE69kpW46xqtAN9ocl1 8X9cmGK9n783KL9zXwo8tU8AEd/0lFj2g+byAouA3u3MmEBoqQL31FZ27V0cLBr5vjPyIi RZk9asElyAjXN2UoAvRMh5IuQf9Y+x/Un3m44kMRBnqpac/7UBnirpkhwqbc1pEfaIWefu 66ef+Be0bCHqAcrC1xxUyCdEE9bbI4Xl2/dUGGWGU88MTqZ0sulGLrAdYK6EbyWjhPU/ut +K+oorLAHbvbwdLNDudTBzHc7e9Imm+lzrJCRhTbTNzZ+BESr/Bcvzbtc3wWCw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=ZqOeLykq; 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" Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qcLJY-0004cy-4p; Sat, 02 Sep 2023 03:45:04 -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 1qcLJW-0004cW-BF for emacs-orgmode@gnu.org; Sat, 02 Sep 2023 03:45:02 -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 1qcLJQ-0003Ss-AE for emacs-orgmode@gnu.org; Sat, 02 Sep 2023 03:45:02 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 3E4B2240029 for ; Sat, 2 Sep 2023 09:44:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1693640694; bh=dhn3UAemicGnu8WX/wT5fRJ7qZ/ZncJDdcSdBfz3p7Y=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=ZqOeLykqBCwnHJ0ha/cvq8CkcbyBCLWYpd+Nn0yEsl27GOtpB2sCES9U1T0hDZ5Y/ VCV8PSULxvC9i4kDMI/QxhJtCcUVYF8vPk93RMN+hRJPh1dhOAwxmbTLwsAy6DRZ+C IilUC6oPdu1RoiKT3I3uw0U99b9XuZ7/6fCEuskTMdAdCavgnWbBAAEwNrQE8Moh/T WxWVmw8b5jRZ5+yb3vk+D4Z9uVPzSMg80qsuo37COHEyhSuSq/A6ioBBmRCWH3PSq8 pVqB0wBkXtpSKA2Eg2CzcIsUleebDFr+d6cVxqvb3fSmzeVWXkjHi5tvDTE4cG3Q5+ RAmwV4H5G0VWw== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Rd6PK10Trz9rxF; Sat, 2 Sep 2023 09:44:52 +0200 (CEST) From: Ihor Radchenko To: Tom Gillespie Cc: "Dr. Arne Babenhauserheide" , Max Nikulin , Bastien , Timothy , Csepp , emacs-orgmode@gnu.org 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/)]) In-Reply-To: References: <87il8v2q00.fsf@riseup.net> <89434f4f-8aea-23f2-bbfc-3961c18f2154@gmail.com> <87a5u6tgb3.fsf@localhost> Date: Sat, 02 Sep 2023 07:45:33 +0000 Message-ID: <87v8ctggrm.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=unavailable 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-Queue-Id: 068899E02 X-Migadu-Scanner: mx0.migadu.com X-Migadu-Spam-Score: -4.51 X-Spam-Score: -4.51 X-TUID: yJYjzH5g67mi Tom Gillespie writes: > My suggestion is as follows. Schemes/prefixes defined by the > #+link: keyword can be used without surrounding syntax markers > but may not contain spaces etc. > ... To support this Org parsers > should always parse prefix:suffix as a _putative_ link which > must then be checked against a list of known schemes that > are either built in or have been declared by the user to indeed > be legitimate schemes. > > In the tel: case, the way to solve the original bug is simply > to add the line #+link: tel tel: which would tell Org that e.g. > tel:555-555-5555 is a real uri, and that it should expand to > itself. Currently, link abbreviations are explicitly allowed in bracket links and only bracket links. The currently available way to force tel: link type is using angle links: No special #+link keyword is needed in the above example. > At the same time this solution would avoid Arne's issue > (which I also have in some of my documents where I have > use fig: and tbl: as prefixes in names and reference them > via [[fig:figure-name]]) because the parser would only treat > prefix: in an internal link as a scheme if it is defined explicitly > by the user in a #+link: keyword or in their init.el. The most annoying part is that we have three not fully consistent link markups: http://plain-link.com [[http://bracket-link.com]] The plain link only works for `org-link-types' - registered link types. The angle link works all the time, unconditionally parsing with "foo" being link type and "bar" being link path. Abbreviations are ignored. The bracket link works only for `org-link-types' __and__ link abbreviations. If whatever inside brackets is not matching know link type or abbreviation, it is considered a fuzzy link. As you see, the situation might easily get confusing in corner cases. My proposal aims to extend the bracket link a bit - the most commonly used link type. However, it creates a problem with fuzzy links. Even more problematic is plain link type where any kind of open syntax will likely clash with normal text flow with innocent text like A:B being suddenly considered a link. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at