From: Kierin Bell <fernseed@fernseed.me>
To: Ihor Radchenko <yantar92@posteo.net>
Cc: emacs-orgmode@gnu.org
Subject: Re: [PATCH] lisp/org-id.el: Add new relative timestamp feature for `ts' `org-id-method'
Date: Wed, 31 May 2023 16:04:28 -0400 [thread overview]
Message-ID: <87r0qw8dyr.fsf@fernseed.me> (raw)
In-Reply-To: <87a5xkoq6p.fsf@localhost> (Ihor Radchenko's message of "Wed, 31 May 2023 08:33:50 +0000")
Ihor Radchenko <yantar92@posteo.net> writes:
> Kierin Bell <fernseed@fernseed.me> writes:
>
>> 3. I have implemented a check to verify that `org-id-ts-relative-function' is
>> only called in Org mode buffers. But since I am uncertain about all of
>> the possible contexts in which `org-id-new' can be called, I am not
>> completely sure if it is adequate:
>>
>> --8<---------------cut here---------------start------------->8---
>> (defun org-id-ts-relative-get-effective ()
>> "Get an effective time using `org-id-ts-relative-function'.
>>
>> Ensure that `org-id-ts-relative-function' is only called in the
>> proper environment (an Org buffer), and return nil otherwise."
>> (when (and (derived-mode-p 'org-mode)
>> (functionp org-id-ts-relative-function))
>> (funcall org-id-ts-relative-function)))
>> --8<---------------cut here---------------end--------------->8---
>
> I do not like this approach too much.
> I think that more reliable approach would be adding a new optional
> argument CONTEXT to `org-id-new'. Then, `org-id-get' can pass the
> context (buffer marker) letting `org-id-new' know the aimed location of
> the newly created ID.
I think that your suggestion is a better idea.
It might also be a good idea to refactor `org-id-new' so that the
different ID methods are more composable.
One nice way to do this would be to create a new option that supersedes
(but does not override) `org-id-method' and takes a list of functions
that are tried in order, so that:
(setopt org-id-method 'ts
org-id-ts-relative t
org-id-ts-relative-function
#'org-id-ts-relative-from-keyword-or-property)
... would be equivalent to:
(setopt org-id-function-list '(org-id-relative-ts-keyword
org-id-relative-ts-property
org-id-ts))
It would then be easy, for example, to instead set the variable so that
a timestamp value is searched for in properties first *and then* in
keywords if that fails.
Or, perhaps someone will want to implement an `org-id-semantic-ts' ID
method that takes a file with the keywords:
#+title: Title of File
#+date: [2023-06-01 Thu 00:00]
...And creates an ID that looks like:
20230601T000000--title-of-file+0.000000
Users could abuse my new `org-id-ts-effective-format' option to achieve
this, or we could add an `org-id-ts-infix' option, and so on. But it
would be better to have ID methods that are each narrowly focused in
purpose, with an easy extension mechanism so that we won't have any
qualms about the focus being too narrow.
I do understand that ID methods may be intentionally difficult to
extend, because IDs should be stable and consistent. But I don't think
that extensibility, human-friendliness and consistency are necessarily
mutually exclusive.
So, what do you think about the `org-id-function-list' option?
Either way, I'll work on refactoring the patch to make things as modular
as possible.
--
Kierin Bell
GPG Key: FCF2 5F08 EA4F 2E3D C7C3 0D41 D14A 8CD3 2D97 0B36
next prev parent reply other threads:[~2023-05-31 20:07 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-16 16:48 [PATCH] lisp/org-id.el: Add new relative timestamp feature for `ts' `org-id-method' fernseed
2023-04-17 11:29 ` Ihor Radchenko
[not found] ` <87v8gac9uy.fsf@localhost>
[not found] ` <87r0qxo8z5.fsf@fernseed.me>
[not found] ` <87a5xkoq6p.fsf@localhost>
2023-05-31 20:04 ` Kierin Bell [this message]
2023-06-01 8:50 ` Ihor Radchenko
2023-07-02 11:00 ` Ihor Radchenko
2023-07-03 14:36 ` Kierin Bell
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=87r0qw8dyr.fsf@fernseed.me \
--to=fernseed@fernseed.me \
--cc=emacs-orgmode@gnu.org \
--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).