* Ihor Radchenko <yanta...@posteo.net> [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?1231...@gnu.org with parts being: mid : /home/user/Maildir ? 1231...@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/
