Re: [PATCH v3] Re: [BUG] org-attach-id-ts-folder-format fails on customized IDs [9.6 (9.6-??-2e9999783)]

[Max Nikulin]

On 13/08/2022 12:29, Ihor Radchenko wrote:
> Max Nikulin writes:
>
> > I believe that interaction between `org-attach-dir-from-id' and members
> > of `org-attach-id-to-path-function-list' could be improved. If a too
> > short ID is passed to `org-attach-id-uuid-folder-format',
> > `org-attach-id-ts-folder-format', or a user-defined function, they may
> > return nil and `org-attach-dir-from-id' should try next element from the
> > list. If nothing succeeds then a user error should be signaled demanding
> > to implement a strategy to properly deal with peculiar IDs.
>
> 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.

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

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.