Kierin Bell <ferns...@fernseed.me> 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 <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
