Kierin Bell <> writes:

> 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))

This will be breaking.
We can do it slightly differently:

1. Allow `org-id-method' to be a list of methods/functions to try in
   addition to being a symbol.
2. Add new customization `org-id-methods' that will link method names to
   functions: '((ts . org-id-ts) (uuid . ...) (uuidgen . ...) (org . ...)).

That way, old configurations will continue working.

> I do understand that ID methods may be intentionally difficult to
> extend, because IDs should be stable and consistent.

Just by default. We do not constrain users from using arbitrary IDs,
including manually typed.

Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <>.
Support Org development at <>,
or support my work at <>

Reply via email to