From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id OO/4G9O10mO9IgAAbAwnHQ (envelope-from ) for ; Thu, 26 Jan 2023 18:18:11 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id yH7yG9O10mO8DwAA9RJhRA (envelope-from ) for ; Thu, 26 Jan 2023 18:18:11 +0100 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 333F7F130 for ; Thu, 26 Jan 2023 18:18:11 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pL5sI-0000ay-Se; Thu, 26 Jan 2023 12:17:22 -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 1pL5sF-0000aE-UR for emacs-orgmode@gnu.org; Thu, 26 Jan 2023 12:17:19 -0500 Received: from stw1.rcdrun.com ([217.170.207.13]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pL5sD-0003LH-L4 for emacs-orgmode@gnu.org; Thu, 26 Jan 2023 12:17:19 -0500 Received: from localhost ([::ffff:102.87.226.121]) (AUTH: PLAIN admin, TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 0000000000103950.0000000063D2B580.00000E04; Thu, 26 Jan 2023 10:16:48 -0700 Date: Thu, 26 Jan 2023 09:11:15 +0300 From: Jean Louis To: Ihor Radchenko Cc: Bruno Barbier , Max Nikulin , AW , emacs-orgmode@gnu.org Subject: Re: Should Org provide commonly used link types? Message-ID: Mail-Followup-To: Ihor Radchenko , Bruno Barbier , Max Nikulin , AW , emacs-orgmode@gnu.org References: <860cca44-faa3-ce41-3606-f92b50ee00a9@gmail.com> <87a62bnf4t.fsf@localhost> <21750362.EfDdHjke4D@linux.fritz.box> <939b62c1-34ee-051e-405a-328b841d3d16@gmail.com> <63d015e3.050a0220.5bc9c.95f5@mx.google.com> <877cxan56u.fsf@localhost> <87357ylbv5.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87357ylbv5.fsf@localhost> User-Agent: Mutt/2.2.9+54 (af2080d) (2022-11-21) Received-SPF: pass client-ip=217.170.207.13; envelope-from=bugs@gnu.support; helo=stw1.rcdrun.com X-Spam_score_int: -3 X-Spam_score: -0.4 X-Spam_bar: / X-Spam_report: (-0.4 / 5.0 requ) BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 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 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1674753491; 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; bh=L52/fLemw4oa56hPm4Q+onm4lke49he4s0wHjfDj4Fw=; b=mqqhSx5rderCM2OsodYmQo3f03NTqmEKS8K3a75y9PzVWr6T1ceZ/X0UmCA4JlM57NN1ef syTYsLT8xrn/ozrCIwUkZghi9yHe/1yfDBI58inQ0RoVUIpFSfdcuGrsBogFO+wElvKS6z /4q5XLTxKXA6/MzVYagF0ZOWLvy6Ypzu5LzcCnLZ+a4m5YiSUmsg2Fw18biVt4CKtPsadR dkddCwQgp7lMTJMnv0zOzu6iyRlNeye/VY3NdxOtgVT7cLQTLVcgOzNo+XloCoZgvZ2tyP c9AedX9uY7xjxvlqzFJAtt70LXLnys2kbxaW4t+Wg4Eth0086EPMemVBuO6UZg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; 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=none ARC-Seal: i=1; s=key1; d=yhetil.org; t=1674753491; a=rsa-sha256; cv=none; b=nxjRzBSb3piv9nHJX31gTWdx3PCb9fDF45CqsBJdUzGKzmUqdkZTtxr8U8OWKuYJd6vYKy C+QdHVpGgT5s+t6ZtZrvTVkGnuVwzuURfkCgVZZ09IrvdQbwcyiVJerE2GxSeh1Q+trDBW WAVEkWFgH7M+1+1lJIIXjvHc1On0jifN6oFaB8u280GY0+Qv3dTkB7OJNYtwGqfEm5IvQR gIGj5/eB7geS2B2nzEGFMA9Owj/o1RwNEjA6udv1kUJknfy1rHUajf2YQc8sJCnfSwqslF Zb71rjfsCh8bnBhzTnRgQyqdnZCrb5xrWYtJyGNVwB+1qxAbmZMUI0AUzp3oYA== X-Migadu-Scanner: scn1.migadu.com Authentication-Results: aspmx1.migadu.com; dkim=none; 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=none X-Migadu-Spam-Score: 1.13 X-Spam-Score: 1.13 X-Migadu-Queue-Id: 333F7F130 X-TUID: M+uLX+iZrWNk * Ihor Radchenko [2023-01-25 21:15]: > So, the suggested links are: > 1. pdf + page > 2. video/audio + timestamp > 3. epub/djvu/mibi + page > > Note that all these are basically file: links. While we can make users > say pdf:... or video:..., or would be more convenient to extend file: > link instead. Max pointed to experimental proof-of-concept code for pdf > + page in another email. Yes, you could extend file: and make special handlings for various types. > > Message-ID, should support FOLDER+Message-ID > > I am not sure here. How can we utilize FOLDER? It depend on the kind of > external application or Emacs package we use to open the link. If you only provide "mid" and function for user to customize it, that is enough, then user's function must know how to handle it. However, that is not by standard as "mid:" is not meant to be referable from Org. See: https://www.rfc-editor.org/rfc/rfc2392 That URL expects message-id only, with possible content-id mid-url = "mid" ":" message-id [ "/" content-id ] Which means, in turn, that "mid:" shall be reserved only for indexing programs, as RFC mentions "indexed", and I assume that is what was meant with it. Many e-mail clients do not have general indexing of e-mails and yet they internally use Message IDs and have no problems finding it, or may have internal indexing not exposed to user. I do think that my proposal is more flexible, by allowing user to introduce function, user can go away from standard and introduce folder, in the sense: mid:/home/user/Maildir?1231212@gnu.org with parts being: mid : /home/user/Maildir ? 1231212@gnu.org I have many many mbox files on computer, they are used by various programs, there is no single program opening all of mbox-es, and Maildirs, and I have 59869+ Maildirs in total. In case I as user change e-mail client to some indexing one, my function can still discard the file location part and find Message ID Another idea is to use "file:" as usual, for those e-mail Message IDs which are stored in files, in that case function again must be somewhere to detect: - if file is Maildir, mbox - to use Page ID part of "file:" if such exist, as Message-ID or third, new URI scheme can be introduced, such as "message-id:" which supports file and message ID together. Outside of scope of thread: --------------------------- Personally I have it solved with hyperlinks on higher level, they remain immutable inside of Org, while decision making how to open them is decided in their definition. [[elisp:(hyperscope-action 1)][📝 ╔ Notes]] [[elisp:(hyperscope 73361)][Secondary School in Lobolwala]] And there is even more general UUID based hyperlink: [[elisp:(uuid "6ADD037A-31BC-435A-BEC8-FE990EBF2A17")][Secondary School in Lobolwala]] UUID based hyperlinks avoid hard coding hyperlink, and avoid hard coding the action to run hyperlink. Actions for UUID are then defined by user. When capturing UUID hyperlink, name is captured as well to construct Org hyperlink. (defcustom rcd-db-uuid-action-alist '(("people" . cf-people-by-id) ("hyobjects" . hyperscope) ("sobjects" . ignore) ("predicates" . ignore) ("uuid2uuid" . ignore) ("properties" . rcd-notes-properties-list-by-referenced-uuid) ("statsdefinitions" . rcd-r-statistics-view) ("transactions" . rcd-accounts-transaction-edit) ("messages" . rcd-message-edit)) "Database UUID action alist." :group 'rcd :type '(alist)) That way using abstract UUID hyperlinks enables more flexibility, practically more collaboration and accessibility to hyperlinks, as it does not "hard code" the object named "Joe Doe", as that object may go across computers. "Joe Doe" vCard may be opened on computer A, if such has been received, because it has same UUID inside, while on computer B, database entry is opened locally for that UUID, but on computer C, remote database entry is accessed. > > Geo location shall be supported, as it has already many handlers in > > GNU/Linux, then GPX files, GeoJSON files > > Are there any? I only know web handlers. I did search at some point. When you use geographic software, the /usr/share/applications get populated with various handlers, for example: -rw-r--r-- 1 1.2K Jan 11 20:53 marble_geo.desktop with Exec=marble --geo-uri=%u Yes, there are many web based handlers. In Emacs there is `osm' package that can easily use Openstreetmaps as URI handler for "geo:" -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/