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 4JiVAKZhk2X1PwAAkFu2QA (envelope-from ) for ; Tue, 02 Jan 2024 02:06:46 +0100 Received: from aspmx1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id yO18NqVhk2V3RgEAqHPOHw (envelope-from ) for ; Tue, 02 Jan 2024 02:06:46 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=ushin.org header.s=key1 header.b=cXyFJt6J; 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=pass (policy=quarantine) header.from=ushin.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1704157605; 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=bnqH9oKk9TGBKDHTS5YNX0vhb+2N1Vq6hhIHg6o0Bjk=; b=aOUxYV3y6AwcwFPL70rr6opWJ4Dh+sb4WtgEgV3N5qxJyZWMaWcWiL1U7w46BBne1/FSVQ yaXGBB9eTP4uqO9pkbuAeMc4vQxy9w732H1K38jEJxVn8lASc/XqJfbxDXwnCFQ0Mf4RRR v4FxkdsOn84W+ZE3ghWaGEHbEHb1/mtHh3SoW4B4iPryr03lnYlPwD3zX6SdMlu8eBnEbv 960T0FQntKKW4NnCR0Kago+ciMJbzlIZlqixxqkp3Yqd5SIce0B3+YQV+F5N4zf+0tASsz 0qjWp2HjiFmwksp2rH6mD3dnScAvnYc7DIYo46Tp8Vzt2/Yoawi8suTe/6sZJQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1704157605; a=rsa-sha256; cv=none; b=szRhDdKw1xPWe/hh3Iga6UlwuW42vd3jQmY/KISgZ4RmGJTyMBjaeZ1M+RZ219dS9i+m7z NijBOSym464UOAxR8RhQKG7ULzilG/d2fcZ97gKLSSxOOOKpwAUMRsh/W7Ohbzju1fqIys ZiOG34fkvxk/LFyGYkH29RyA4fXZYMwXylanhh14yhKH0/x7FXZb8MAMTiV0lhEBemmJCo /zr0Yy2T41rncTdqSjeCJ6+P1ww3xNXl0omj/xf+ozONCrL502SkwIOP66T8UJNfOfQSJq uaY8NrcDpkk7go1e3+KiBvodDz01jLkl3dZfWveIDTBgk7kPmcAVsrs7IBy4uQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=ushin.org header.s=key1 header.b=cXyFJt6J; 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=pass (policy=quarantine) header.from=ushin.org 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 42DF51781C for ; Tue, 2 Jan 2024 02:06:45 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rKTEC-0006CP-W7; Mon, 01 Jan 2024 20:05:57 -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 1rKTEB-0006Bx-B4 for emacs-orgmode@gnu.org; Mon, 01 Jan 2024 20:05:55 -0500 Received: from out-178.mta0.migadu.com ([2001:41d0:1004:224b::b2]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rKTE3-0000qB-PX for emacs-orgmode@gnu.org; Mon, 01 Jan 2024 20:05:55 -0500 References: <87o7e9ei3p.fsf@ushin.org> <87wmsx3vyc.fsf@localhost> <87a5pro14q.fsf@ushin.org> <87le9a76mk.fsf@localhost> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ushin.org; s=key1; t=1704157541; h=from:from: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; bh=bnqH9oKk9TGBKDHTS5YNX0vhb+2N1Vq6hhIHg6o0Bjk=; b=cXyFJt6J0AgKnapb2ULnMOf37wiHCCiKetbBLniSKhKNjRkuCqqOWCX8fxJDxxyyiOM614 /xVXZMPr3wv4K7MIdlX4LUHVeX1/05p1dU+3feaYUia/jILJ+alAd0hXINIHXUaEz9r1B/ Tz7QRVROiwU/hblBqNC2c+8gicpEz9/p/mwGs4V+KQYzXRdQk7iDyUVPRPesYxaUNNA8Wz kWwRgg3sbCLyN54Fqygicf4qGM4s0rIioygumI3wA+Z0CPjd6e+zg52dS8/fbRUUtoKGUc y15zNaRkkETuS/QrWi254PjpjQH4w/T+TzroPhXNIKnAz7tfFHTLddZToDwBmQ== X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Joseph Turner To: Ihor Radchenko Cc: emacs-orgmode@gnu.org, Adam Porter Subject: Re: Should org-link-parser add type "file" when link has no "file:" prefix? Date: Sun, 31 Dec 2023 22:52:04 -0800 In-reply-to: <87le9a76mk.fsf@localhost> Message-ID: <87wmss1r51.fsf@ushin.org> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2001:41d0:1004:224b::b2; envelope-from=joseph@ushin.org; helo=out-178.mta0.migadu.com X-Spam_score_int: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.1 / 5.0 requ) BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 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-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -8.71 X-Spam-Score: -8.71 X-Migadu-Queue-Id: 42DF51781C X-Migadu-Scanner: mx11.migadu.com X-TUID: hKx7Uaxelc9X Ihor Radchenko writes: > 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. Thanks! Are you suggesting something like [[file+hyper:/README.org]] ? >> 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. Yes, there are many users who rely on [[file:/index.html]] exporting to instead of . > Why not make [[hyper:/README.org]] use the "default" hyperdrive the > Org file belongs to. I'd like for users to be able to take an existing directory of Org mode documents and copy them all into a hyperdrive. I think the least surprising behavior is for the links between those files to continue working. Perhaps the best option is for hyperdrive.el to make all "file" type links, explicit or not, point to other files inside the hyperdrive? In that case, there would be no way for Org mode files in a hyperdrive to point to the local filesystem. Similarly, when Org documents are exported to HTML, there's no way to export . >> 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/ How would the :follow function for "file:" links get access to the link search option? IIUC, `org-link-open' handles "file:" links specially because they require (org-element-property :search-option link) Thank you!!! Joseph