From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id kB0FFizrpmXsPQAAqHPOHw:P1 (envelope-from ) for ; Tue, 16 Jan 2024 21:46:36 +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 kB0FFizrpmXsPQAAqHPOHw (envelope-from ) for ; Tue, 16 Jan 2024 21:46:36 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=ushin.org header.s=key1 header.b=ctFgsrOf; dmarc=pass (policy=quarantine) header.from=ushin.org; 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=1705437996; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=1G37vs+ypy8pzUhdVcTu/7tibH/zVIP1wKsRunxMuQ8=; b=JNKwFjgYqSTdT+QGpJ/vr54HkQdXJxwdB+Tk0GM/LcFgT6wZ3/JmZu3C7/Trzh64hT9Gl3 FGjFXATrQu0oid9NtETyhWjPYfZXfYiWtpqFHqfciQW3mLsD0TFvrk8qcduJ+pvii3/0y7 TaFklEk+mbk80B4zEIpwYTps0rWP5xmm8JCt4l/TW3IzMx5Z9qrnKiNysSTabZOdMa6X50 GDeMI/bjClVCMiqMKSvPIJVWiDDkAqIZ9/v+JQFHcND0+x4oEMA1H/N0q4awMiBxEgQMvi w89Tnzgxvai9vFpTcWRYS2N96Voyn9RzU52A5/myxu3SA+IVApiy8uK7hdORZA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=ushin.org header.s=key1 header.b=ctFgsrOf; dmarc=pass (policy=quarantine) header.from=ushin.org; 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=1705437996; a=rsa-sha256; cv=none; b=iIvEyuJkRS1auQCxrAqAA/F2w3pjOEucbgNodv88VvC7CBlPZUW2dqCmxdY0ysfuDP7k1V SJoGbQlXv0UTy8v7Fvz6UumMnznhtZHFricw2am3sHlEek2ZlNlxu/spoDplh+dUGYuDgT TH9+EBr/OoMrECn87PbN6qPyltnI5gj5hfwAgboLT8zxIz/pGFeBuPKyvrIuaarq9Zx/Ti n8DTJUo7im49MbHCMXpqWFfs/D6wNF2CnwWXSETG3l930mPpehRDeIxMD7HBGevDNu+Xf0 SgcDmtCTPfSZIc/UywJJCQjX0ZzaC2/Kq8Ofagwmyg1kSvVdAEwM5h9kb94VOw== 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 D10CF15516 for ; Tue, 16 Jan 2024 21:46:35 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rPqJE-00016V-Il; Tue, 16 Jan 2024 15:45:20 -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 1rPqJ5-00015f-Sf for emacs-orgmode@gnu.org; Tue, 16 Jan 2024 15:45:11 -0500 Received: from out-176.mta0.migadu.com ([91.218.175.176]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rPqIy-0005G4-Vb for emacs-orgmode@gnu.org; Tue, 16 Jan 2024 15:45:07 -0500 References: <87o7e9ei3p.fsf@ushin.org> <87wmsx3vyc.fsf@localhost> <87a5pro14q.fsf@ushin.org> <87le9a76mk.fsf@localhost> <87wmss1r51.fsf@ushin.org> <87ttnvan3m.fsf@localhost> <87v87v0zno.fsf@ushin.org> <87le8pl7lw.fsf@localhost> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ushin.org; s=key1; t=1705437899; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=1G37vs+ypy8pzUhdVcTu/7tibH/zVIP1wKsRunxMuQ8=; b=ctFgsrOfqu5O3VF8WFpWiYAWPUMcn6BoYLmdXwA7SzysdwVoSfwQoYTFI2TGp4jdfrXuKy IfTf5zlxMpxWA1CJ54W2nV46LaXxvEgc9PUHEgJkU+CRn51V+20VYBjWdSmMwNiU+oFfr6 y/DvG9vmP4ljAAKEvgkIZ8lyjtU2KaLWFw9PfAWty+FVOwMje5UG5wbKa4gvbpyDJDKX+B SASsplYFwYZ6GfuHzyokrOGn0+Y/CaLCNXuKNScK4vXJu1e8MxGmKs6dzyQ+fiQYdWZejP he186AYfPWgNQEpL4vFa1lMM27+7SjeQXoIa4iI6JVh0o3jPqncSTOOgM1Z0Rw== 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: Tue, 16 Jan 2024 12:16:34 -0800 In-reply-to: <87le8pl7lw.fsf@localhost> Message-ID: <87mst5f1o9.fsf@ushin.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=91.218.175.176; envelope-from=joseph@ushin.org; helo=out-176.mta0.migadu.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, 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: -6.89 X-Spam-Score: -6.89 X-Migadu-Queue-Id: D10CF15516 X-Migadu-Scanner: mx12.migadu.com X-TUID: izV7TbGUMjoE Ihor Radchenko writes: > Joseph Turner writes: > >>>> 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 "fi= le" >>>> type links, explicit or not, point to other files inside the hyperdriv= e? >>>> >>>> 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 . >>> >>> May you please elaborate? How is hyperdrive directory different from >>> local directory? >> >> On disk, hyperdrive data is stored by hash prefixes like so: >> >> /home/joseph/.local/share/hyper-gateway-nodejs/cores/ >> =E2=94=94=E2=94=80=E2=94=80 00 >> ... >> This is similar to the way .git/objects/ directories are structured. >> ... >> Does that answer your question? > > Not really. > May you please provide an example with an Org file containing file links > and how you envision to transform them? Will they be transformed > depending on the directory the Org file is located in? I don't want to transform the file links. The idea is that an Org file "foo.org" could be copied into a hyperdrive, and [[./bar.org]] would point to a file called "bar.org" in the same folder in the hyperdrive. That way, you could copy both "foo.org" and "bar.org" from your local directory into a hyperdrive, the links between them would work as-is. Pseudo-code for a hyperdrive.el :follow function for file: links: (defun hyperdrive--org-file-link-follow (url &optional _prefix _link) (when hyperdrive-mode (hyperdrive-open (hyperdrive-convert-path-to-hyper-url url option)) ;; Turns "/foo" in= to "hyper://PUBLIC-KEY/foo" t)) (org-link-set-parameters "file" :follow #'hyperdrive--org-file-link-follow) >>>> (org-element-property :search-option link) >>> >>> :follow functions are passed both path and search option. >> >> How is the search option passed in? >> >> IIUC in org-link-open, the path argument passed in has no search option: >> >> (funcall (org-link-get-parameter type :follow) path arg) > > You are right. > What we can do then is pass an extra argument to :follow function - the > link object. That way, :follow function can get all the information it > needs. I like this idea! Would this change break existing :follow functions which only expect max two args? >> By the way, I think this minor improvement could be made at the bottom >> of org-link-open: >> >> From 0c83446f16441df39618e43f964e18f672205d55 Mon Sep 17 00:00:00 2001 >> From: Joseph Turner >> Date: Mon, 15 Jan 2024 00:24:30 -0800 >> Subject: [PATCH] lisp/ol.el (org-link-open): Use let-bound :follow funct= ion > > Thanks! > Applied, onto main; I added TINYCHANGE cookie to the commit message. > https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=3D0254854= ee Thanks! Joseph