RE: [Bug] org-store-link should not insert a document level ID property

["Gustav Wikström" <gustav@whil.se>]

Hi,

> -----Original Message-----
> From: Nicolas Goaziou <mail@nicolasgoaziou.fr>
> Sent: den 13 maj 2020 18:45
> To: Matthew Lundin <mdl@imapmail.org>
> Cc: Gustav Wikström <gustav@whil.se>; Org Mode List <emacs-orgmode@gnu.org>
> Subject: Re: [Bug] org-store-link should not insert a document level ID
> property
> 
> Matthew Lundin <mdl@imapmail.org> writes:
> 
> > Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
> >>
> >> AFAIK, ID is associated to a file name, and possibly a location in it.
> >> In this case, the ID is strictly equivalent to the file name, so why
> >> bother?
> >
> > I'm not sure I understand the question. Are you asking: Why bother
> > generating IDs at the top level of a file (which was the change Gustav
> > introduced)? Or why bother turning off that behavior? I can't address
> > the former question but I will address the latter.
> 
> Sorry for not being clear. This was the first question. I don't
> understand why we are generating an ID for the whole file.

I see some purposes. They maybe aren't for everyone, but they surely are there. 
1) Attachments for the whole file without setting the DIR property.
2) Link targets, making the file name irrelevant for the links.

> > The main reason is that I find these IDs redundant and visually
> > distracting. I can see how file IDs would be useful if one is
> > constantly renaming files (or perhaps writing custom functions that
> > convert files to entries and vice versa).
> 
> IIUC, currently, renaming the file breaks the association between the ID
> and the file name. IOW, the ID is useless if you rename the file.

As long as org-id-track-globally isn't set to nil I don't think what you write is true. And even if renaming the file would break the link it's just momentarily since regenerating the .org-id-locations file should make the link work again.

Regards
Gustav