Re: Should Org provide commonly used link types?

[Jean Louis]

* Ihor Radchenko <yantar92@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?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/