From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:303:5f26::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id eFwzJTSDkWU1QgAAkFu2QA (envelope-from ) for ; Sun, 31 Dec 2023 16:05:24 +0100 Received: from aspmx1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id mAljHjSDkWXPEAAAqHPOHw (envelope-from ) for ; Sun, 31 Dec 2023 16:05:24 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; none 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 632181B911 for ; Sun, 31 Dec 2023 16:05:24 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rJxMe-000377-N0; Sun, 31 Dec 2023 10:04:32 -0500 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 1rJxMc-00035M-GB for emacs-orgmode@gnu.org; Sun, 31 Dec 2023 10:04:30 -0500 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 1rJxMV-0004Oo-AP for emacs-orgmode@gnu.org; Sun, 31 Dec 2023 10:04:30 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 935B7240028 for ; Sun, 31 Dec 2023 16:04:19 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1704035059; bh=n3LydLylRaFPFuPAys+UwqZv7H6qJeHMIQt03UdZYOo=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=Is0ZzRMod8JHVy7SCO/gRkScGV7dJAY6IvS8/9/eRpzXi0Ao6XRlRPijSgAum3WCP WZAePEYLqWizNvq8SFfBV+d0rWhrr4XkiAR2Xx+mpgPGl4jVdYOIcGAJZ5MFVzOEfb YIak7pInDSbwh2SxwJKRjljiLOH65MmQfmHmAmDiDfcmuiCBPgr/3cx385MBFOQJWV zAGxlL+qgr5COPKlS5Nkqkp2tmct+uyVTrZW/eRo9xuAGlhZzVxdshuxN5mzdcigP8 cYGSvwolz4SN55xfojmLoH6I0mB9rSCx3kiTbZQlfhugzZmLeLDUqltoV0xmJeIT4z FW69UwUA0XdhQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4T32Sy4278z6twB; Sun, 31 Dec 2023 16:04:18 +0100 (CET) From: Ihor Radchenko To: Joseph Turner Cc: emacs-orgmode@gnu.org, Adam Porter Subject: Re: Should org-link-parser add type "file" when link has no "file:" prefix? In-Reply-To: <87a5pro14q.fsf@ushin.org> References: <87o7e9ei3p.fsf@ushin.org> <87wmsx3vyc.fsf@localhost> <87a5pro14q.fsf@ushin.org> Date: Sun, 31 Dec 2023 15:07:31 +0000 Message-ID: <87le9a76mk.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: -53 X-Spam_score: -5.4 X-Spam_bar: ----- X-Spam_report: (-5.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=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 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-Spam-Score: -4.00 X-Spam-Score: -4.00 X-Migadu-Queue-Id: 632181B911 X-Migadu-Scanner: mx12.migadu.com X-TUID: spw3/3185RYF Joseph Turner writes: >> It would be more reliable to provide a separate link type. >> We might even extend the special file+application: link type syntax that >> already allows special behavior for opening file links. > > Thank you! Would you explain about extending file+application syntax? See `org-open-file' IN-EMACS argument - we may use different handlers to open file links. Currently, IN-EMACS can be 'system or 'emacs. But nothing stops us from adding more options. > hyperdrive.el does add a separate "hyper://" link type which is used to > link to a hyperdrive file or directory by its "full" URL: > > hyper://aaj45d88g4eenu76rpmwzjiabsof1w8u6fufq6oogyhjk1ubygxy/hyperdrive/hyperdrive-manual.org > > Additionally, we want to make it possible for users to copy ("mirror") a > directory of Org mode documents into a hyperdrive for other users to > view and link to. Ideally, when users upload a set of files to a > hyperdrive, the relative and absolute links between those files within > the same hyperdrive work without modification. > > We also wanted users to be able to link to files on the local filesystem > from within a hyperdrive. Firefox and Chrome treat prefix-less links as > pointers to files on the same webserver and "file:" links as pointers to > files on the filesystem. We thought that we could do the same thing in > hyperdrive.el: [[/README.org]] could point to a file in the same > hyperdrive while [[file:/README.org]] could point to a local file. This will cause major issues when trying to export such links. Except for HTML export that utilizes `org-html-link-use-abs-url', but only for relative links. Why not make [[hyper:/README.org]] use the "default" hyperdrive the Org file belongs to. > Would you be open to changing Org mode so that prefix-less links could > be handled in a special way by certain modes? Here's an idea: > > - Add a buffer-local variable `org-current-uri-scheme' which could be > set to a string like "hyper". > > - When handling "file" type links, check if `org-current-uri-scheme' > matches one of the keys in `org-link-parameters', and use the > appropriate handler instead of the "file" handler. (see attached patch > for an example usage in `org-link-open') > > What do you think? IMHO, it is too specific for Org core. What we might do is allow setting :follow function for file: links. We generally aim to remove hard-coded link types from `org-link-open', exposing them to `org-link-set-parameters'. For example, see WIP patch where we expose setting id: link properties: https://list.orgmode.org/orgmode/c98a38b0-6dea-4b5c-b00f-a39ea922537f@app.fastmail.com/ -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at