From: Max Nikulin <manikulin@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: [PATCH v2] org-attach.el: ID to path functions may return nil
Date: Tue, 15 Nov 2022 23:41:35 +0700 [thread overview]
Message-ID: <tl0fg0$16cp$1@ciao.gmane.io> (raw)
In-Reply-To: <878rkddjng.fsf@localhost>
On 15/11/2022 09:41, Ihor Radchenko wrote:
> Max Nikulin writes:
>>
>> Please, remove a stray space in the defcustom.
>
> Hmm. Done.
>
> I just have a habit to add space in the first item in a list because it
> helps auto-indentation.
I had an impression that something was wrong with indentation of next
entries.
>>> I also added the dumb fallback to the default value.
>>> I feel that otherwise the description of too confusing.
>>
>> I am unsure concerning adding it to the default value. From my point of
>> view, it is better to ask user to clarify their intention.
> Handling too short IDs is a different issue indeed, but why not to fix
> it as well?
I still have a different opinion, but it should not prevent you from
committing your variant. The issue is not critical.
The problem is not too short ID. Actually they are some ID having
unknown format, so functions designed for particular ID generation
methods may cause a mess in attachment subdirs.
>> If strict variants of functions were used above then non-standard IDs
>> would be isolated in the directory returned by the next entry
>
> Good point.
> What about using the value you provided in the NEWS as an actual default?
It may be done by a next patch unless other issues will attract more
attention.
>> `org-attach-id-uuid-folder-format' and `org-attach-id-ts-folder-format'
>> here were added for users changed `org-id-method' in the past and so
>> having mixed subdirs layout with UUIDs in 6 character prefix directories
>> or timestamps in two characters folders.
>
> Agree. Fixed.
> +(setq org-attach-id-to-path-function-list
> + '(;; When ID looks like an UUIDs or Org internal ID, use
> + ;; `org-attach-id-uuid-folder-format'.
> + (lambda (id)
> + (and (or (org-uuidgen-p id)
> + (string-match-p "[0-9a-z]\\{12\\}" id))
> + (org-attach-id-uuid-folder-format id)))
> + ;; When ID looks like a timestap-based ID. Group by year-month
> + ;; folders.
> + (lambda (id)
> + (and (string-match-p "[0-9]\\{8\\}T[0-9]\\{6\\}\.[0-9]\\{6\\}" id)
> + (org-attach-id-ts-folder-format id)))
> + ;; Fallback to handle previous defaults.
> + org-attach-id-uuid-folder-format
> + org-attach-id-ts-folder-format
> + ;; Any other ID goes into "important" folder.
> + (lambda (id) (format "important/%s/%s" (substring id 0 1) id))))
Sorry, but "important" entry should be before
`org-attach-id-uuid-folder-format'. My idea is the following:
- If the ID was generated by 'uuid or 'org `org-id-method' then prefer
XX/... subfolder. It is important for new attachments. Even if current
`org-id-method' is 'ts then this entry is ignored and layout is
determined by the next entry.
- If the ID is timestamp-based then prefer "YYYYMM/DDTIME" subfolder.
- Put new non-standard IDs to important/X/... subfolder whenever
particular ID is a short or a long one.
- Handle the case of `org-id-method' changed in the past from timestamp
to UUID or vice versa. Try to find attachment trying to split 2
characters from timestamp or 6 characters from UUID. So add bare
`org-attach-id-uuid-folder-format' and `org-attach-id-ts-folder-format'.
These 2 entries may be skipped for new users or for users who never
experienced change of `org-id-method'.
next prev parent reply other threads:[~2022-11-15 16:42 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-20 19:12 [BUG] org-attach-id-ts-folder-format fails on customized IDs [9.6 (9.6-??-2e9999783)] Janek F
2022-07-23 5:22 ` [PATCH] " Ihor Radchenko
2022-08-02 22:26 ` Janek F
2022-08-03 16:03 ` Max Nikulin
2022-08-03 22:25 ` Ihor Radchenko
2022-08-10 11:43 ` [PATCH v2] " Ihor Radchenko
2022-08-10 12:17 ` Max Nikulin
2022-08-10 13:23 ` [PATCH v3] " Ihor Radchenko
2022-08-10 15:18 ` Max Nikulin
2022-08-11 4:19 ` Ihor Radchenko
2022-08-11 14:43 ` Max Nikulin
2022-08-13 5:29 ` Ihor Radchenko
2022-08-13 16:25 ` Max Nikulin
2022-08-14 4:00 ` Ihor Radchenko
2022-10-02 9:14 ` [PATCH v4] " Ihor Radchenko
2022-10-04 15:27 ` Max Nikulin
2022-10-05 5:44 ` Ihor Radchenko
2022-11-06 7:43 ` Ihor Radchenko
2022-11-07 17:05 ` [PATCH] org-attach.el: ID to path functions may return nil Max Nikulin
2022-11-08 5:08 ` Ihor Radchenko
2022-11-09 16:53 ` [PATCH v2] " Max Nikulin
2022-11-10 7:19 ` Ihor Radchenko
2022-11-13 16:26 ` Max Nikulin
2022-11-14 3:29 ` Ihor Radchenko
2022-11-14 16:59 ` Max Nikulin
2022-11-15 2:41 ` Ihor Radchenko
2022-11-15 16:41 ` Max Nikulin [this message]
2022-11-16 1:54 ` Ihor Radchenko
2022-08-12 15:35 ` [BUG] org-attach-id-ts-folder-format fails on customized IDs [9.6 (9.6-??-2e9999783)] Max Nikulin
2022-08-12 16:08 ` Janek F
2022-08-13 5:17 ` Ihor Radchenko
2022-08-13 15:59 ` Max Nikulin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='tl0fg0$16cp$1@ciao.gmane.io' \
--to=manikulin@gmail.com \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).