Hi Marc-Oliver,
Marc-Oliver Ihm writes:
> as I use the excellent package org-id in a somewhat non-standard way,
> I tend to produce IDs, that are not referenced from anywhere. Org-id
> handles this great and does not suffer in performance, but eventually
> I want to remove those unreferenced IDs
Hi Adam,
thanx for your feedback !
Your main point (the central function beeing to long) is undisputed;
will fix this during the next refactoring ...
Best regards,
Marc
Am 13.04.2020 um 22:04 schrieb Adam Porter:
Marc-Oliver Ihm writes:
as I use the excellent package org-id in a somewhat non-s
Hi Ihor,
Thanx ! Fixed it.
Details: I am now checking
(string= (org-attach-dir-from-id id) (org--attach-dir))
to see if the ID is used in the attachment dir (if it exists).
Background: I do not use attachments myself;
did not remember, they use IDs :-/
Best regards,
Marc
Am 14.04.2020 um 05:02 sc
I quickly looked through the code. It seems that you do not consider
attachments, which are normally stored in a folder named after the
entry's ID property. Deleting those ID is terrible idea.
Best,
Ihor
Marc-Oliver Ihm writes:
> Hi,
>
> as I use the excellent package org-id in a somewhat non-
Marc-Oliver Ihm writes:
> as I use the excellent package org-id in a somewhat non-standard way,
> I tend to produce IDs, that are not referenced from anywhere. Org-id
> handles this great and does not suffer in performance, but eventually
> I want to remove those unreferenced IDs. Therefore I ha
Hi,
as I use the excellent package org-id in a somewhat non-standard way, I tend to
produce IDs, that are not referenced from anywhere. Org-id handles this great
and does not suffer in performance, but eventually I want to remove those
unreferenced IDs.
Therefore I have written a small interact
