Max Nikulin <maniku...@gmail.com> 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