From: Jean Louis <bugs@gnu.support>
To: Ihor Radchenko <yantar92@posteo.net>
Cc: Bruno Barbier <brubar.cs@gmail.com>,
Max Nikulin <manikulin@gmail.com>,
AW <alexander.willand@t-online.de>,
emacs-orgmode@gnu.org
Subject: Re: Should Org provide commonly used link types?
Date: Thu, 26 Jan 2023 09:11:15 +0300 [thread overview]
Message-ID: <Y9IZg4CV2crbjffi@protected.localdomain> (raw)
In-Reply-To: <87357ylbv5.fsf@localhost>
* 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/
next prev parent reply other threads:[~2023-01-26 17:18 UTC|newest]
Thread overview: 88+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <draft-87r0vhxg15.fsf@tosh-laptop.mail-host-address-is-not-set>
2023-01-21 21:32 ` Link from orgmode file to E-Mail (using kmail or notmuch) AW
2023-01-21 22:43 ` Gautier Ponsinet
2023-01-22 4:44 ` Max Nikulin
2023-01-22 8:32 ` Ihor Radchenko
2023-01-22 9:38 ` Jean Louis
2023-01-22 10:36 ` Max Nikulin
2023-01-22 18:47 ` AW
2023-01-23 6:19 ` Jean Louis
2023-01-23 10:40 ` Ihor Radchenko
2023-01-23 13:55 ` AW
2023-01-23 18:28 ` Jean Louis
2023-01-24 9:40 ` Ihor Radchenko
2023-01-24 10:42 ` Dirk-Jan C. Binnema
2023-01-24 11:17 ` Ihor Radchenko
2023-01-24 17:08 ` Dirk-Jan C. Binnema
2023-01-24 19:12 ` Jean Louis
2023-01-26 10:01 ` AW
2023-01-24 19:01 ` Jean Louis
2023-01-28 14:08 ` [OT] email opens (was: Link from orgmode file to E-Mail (using kmail or notmuch)) Gregor Zattler
2023-01-28 18:26 ` tomas
2023-01-29 4:37 ` Jean Louis
2023-01-26 9:58 ` Link from orgmode file to E-Mail (using kmail or notmuch) AW
2023-01-26 10:16 ` Ihor Radchenko
2023-01-26 11:43 ` Max Nikulin
2023-01-26 12:18 ` Jean Louis
2023-01-26 18:41 ` AW
2023-01-23 11:46 ` Max Nikulin
2023-01-23 13:59 ` AW
2023-01-23 14:20 ` AW
2023-01-24 9:44 ` Ihor Radchenko
2023-01-24 16:11 ` Max Nikulin
2023-01-24 17:32 ` Bruno Barbier
2023-01-25 12:48 ` Max Nikulin
2023-01-28 2:36 ` Max Nikulin
2023-01-28 8:30 ` Bruno Barbier
2023-01-28 8:30 ` Max Nikulin
2023-01-31 19:56 ` PATCH for worg about cb_thunderlink (Re: Link from orgmode file to E-Mail (using kmail or notmuch)) Bruno Barbier
2023-02-01 16:18 ` Max Nikulin
2023-02-01 18:16 ` Bruno Barbier
2023-02-02 14:47 ` Max Nikulin
2023-02-02 6:04 ` Bruno Barbier
2023-02-03 14:50 ` Max Nikulin
2023-02-03 15:42 ` Bruno Barbier
2023-02-04 4:59 ` Max Nikulin
2023-02-06 11:46 ` Bruno Barbier
2023-02-07 15:08 ` [PATCH] worg/org-faq.org: Recommend cb_thunderlink Thunderbird add-on Max Nikulin
2023-02-07 18:26 ` Bruno Barbier
2023-02-08 15:45 ` Max Nikulin
2023-01-23 18:37 ` Link from orgmode file to E-Mail (using kmail or notmuch) Jean Louis
2023-01-24 17:22 ` Max Nikulin
2023-01-24 17:49 ` Jean Louis
2023-01-25 15:31 ` Max Nikulin
2023-01-25 16:48 ` This is out of thread subject Jean Louis
2023-01-25 18:01 ` Ihor Radchenko
2023-01-26 6:28 ` Jean Louis
2023-01-27 11:23 ` Ihor Radchenko
2023-01-27 11:51 ` Firefox permission dialog and org-protocol Max Nikulin
2023-01-29 13:50 ` Ihor Radchenko
2023-01-30 5:48 ` Max Nikulin
2023-01-30 14:59 ` [BUG] org-manual: Using bookmarklet for org-capture is no longer reliable (was: Firefox permission dialog and org-protocol) Ihor Radchenko
2023-01-31 8:11 ` [BUG] org-manual: Using bookmarklet for org-capture is no longer reliable Charles Philip Chan
2023-01-31 12:20 ` Max Nikulin
2023-02-01 13:38 ` Ihor Radchenko
2023-02-02 14:09 ` Max Nikulin
2023-02-02 14:17 ` Ihor Radchenko
2023-02-02 15:02 ` Max Nikulin
2023-02-05 7:43 ` Max Nikulin
2023-02-05 10:26 ` Ihor Radchenko
2023-01-31 1:59 ` Firefox permission dialog and org-protocol Samuel Wales
2023-01-26 16:19 ` Link from orgmode file to E-Mail (using kmail or notmuch) Max Nikulin
2023-01-27 6:41 ` Jean Louis
2023-01-27 15:19 ` Max Nikulin
2023-01-29 4:18 ` Jean Louis
2023-01-29 8:41 ` Ihor Radchenko
2023-01-24 17:39 ` Bruno Barbier
2023-01-24 17:52 ` Jean Louis
2023-01-25 12:56 ` [FR] Should Org provide commonly used link types? (was: Link from orgmode file to E-Mail (using kmail or notmuch)) Ihor Radchenko
2023-01-25 16:40 ` Should Org provide commonly used link types? Jean Louis
2023-01-25 18:15 ` Ihor Radchenko
2023-01-26 5:09 ` Jean Louis
2023-01-26 6:11 ` Jean Louis [this message]
2023-04-26 18:18 ` jawatech
2023-01-24 9:42 ` Link from orgmode file to E-Mail (using kmail or notmuch) Ihor Radchenko
2023-01-24 15:49 ` Max Nikulin
2023-01-24 18:14 ` Jean Louis
2023-01-24 18:03 ` Jean Louis
2023-01-22 7:29 ` Jean Louis
2023-01-27 18:15 ` Bruno Barbier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y9IZg4CV2crbjffi@protected.localdomain \
--to=bugs@gnu.support \
--cc=alexander.willand@t-online.de \
--cc=brubar.cs@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=manikulin@gmail.com \
--cc=yantar92@posteo.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).