Ihor Radchenko <yanta...@posteo.net> writes:
> Kierin Bell <ferns...@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
