emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: "Gustav Wikström" <gustav@whil.se>
To: Nicolas Goaziou <mail@nicolasgoaziou.fr>,
	Matthew Lundin <mdl@imapmail.org>
Cc: Org Mode List <emacs-orgmode@gnu.org>
Subject: RE: [Bug] org-store-link should not insert a document level ID property
Date: Thu, 14 May 2020 19:27:40 +0000	[thread overview]
Message-ID: <HE1PR0201MB23466ACA8D7EE0A48465FC44DABC0@HE1PR0201MB2346.eurprd02.prod.outlook.com> (raw)
In-Reply-To: <87tv0jbx7j.fsf@nicolasgoaziou.fr>


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


  reply	other threads:[~2020-05-14 19:39 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-04 22:13 Matt Lundin
2020-04-04 23:07 ` Gustav Wikström
2020-04-05 15:50   ` Gustav Wikström
2020-04-10  8:08     ` Gustav Wikström
2020-05-07 21:41     ` Matthew Lundin
2020-05-13  8:33       ` Nicolas Goaziou
2020-05-13 13:26         ` Matthew Lundin
2020-05-13 16:45           ` Nicolas Goaziou
2020-05-14 19:27             ` Gustav Wikström [this message]
2020-05-14 21:20               ` Nicolas Goaziou
2020-05-14 22:06                 ` Gustav Wikström
2020-05-14 19:11       ` Gustav Wikström

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:

  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=HE1PR0201MB23466ACA8D7EE0A48465FC44DABC0@HE1PR0201MB2346.eurprd02.prod.outlook.com \
    --to=gustav@whil.se \
    --cc=emacs-orgmode@gnu.org \
    --cc=mail@nicolasgoaziou.fr \
    --cc=mdl@imapmail.org \
    --subject='RE: [Bug] org-store-link should not insert a document level ID property' \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Code repositories for project(s) associated with this inbox:


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