Max Nikulin <[email protected]> writes:
>> I do not think that it is a good idea. We currently promise to use the
>> first function in the list to generate the IDs. Other functions are
>> mostly a fallback to catch the existing attach dirs created in the past
>> using different ID scheme.
>
> My idea is to add an extra check that filters out nil values. I do not
> mind to signal a user error if first entry from
> `org-attach-id-to-path-function-list' returns nil and paths returned by
> other function do not exist.
This would be possible, in addition to the patch above.
Or do you mean the default ts/uuid format functions to return nil to
short IDs as well?
>> I guess that one option could be demanding a non-nil return value when
>> generating a new attach dir (without TRY-ALL argument) and wrapping
>> things into (ignore-errors ...) otherwise.
>
> I am against `ignore-errors' because it makes harder bug hunting using
> debug on errors.
Agreed.
> I would prefer to force users to justify strategy for non-standard IDs
> as early as possible. The goal is to avoid manual actions to change
> directory structure when users have hundreds of folders. My experience
> that users may easily face performance issues with ~1000 files per
> directory. The reason is either lack of optimization for such case in
> particular application or a bug introduced in a new version.
I am not sure if we can solve this kind of issue reliably. The only idea
is enforcing [1-9][0-9]\{5\} for ts IDs. And we cannot do much about IDs
prefixed with the same constant string.
--
Ihor Radchenko,
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
