From: Aaron Ecay <aaronecay@gmail.com>
To: Nicolas Goaziou <mail@nicolasgoaziou.fr>,
Org-mode <emacs-orgmode@gnu.org>
Subject: Re: Feedback on changes to org-id
Date: Wed, 21 Sep 2016 23:28:55 +0100 [thread overview]
Message-ID: <8760porioo.fsf@gmail.com> (raw)
In-Reply-To: <87oa45z8y2.fsf@saiph.selenimh>
Hi Nicolas,
Thanks for your feedback. I am almost done incorporating it into the
patch. I have only two further questions.
2016ko irailak 3an, Nicolas Goaziou-ek idatzi zuen:
[...]
>> 4. A similar issue arises for org-id-find. I would like it to always
>> return a marker, rather than having an argument switch between a
>> marker and a cons of filename and position. (There are functions
>> which return the filename or position individually, so returning both
>> as a cons is useless from an API point of view). There’s no good way
>> to detect the old calling convention, however, so I think I have to
>> introduce a new name. (My draft patch is written instead with hard
>> breakage, but stability of API is important so I will change
>> that...)
>
> Please don't make that change. A marker is pointless if the file is not
> currently associated to any buffer. In that case (file-name . postition)
> cons cell is a valuable return value.
The API has the following two functions already:
- org-id-find-file-for: id -> file-name
- org-id-find-id-in-file: id file -> position
Imagine I add to this API org-id-find-marker: id -> marker. Then I
think we can deprecate (and eventually delete) org-id-find, since all its
uses can be replaced by some combination of the other 3 functions. (We
could also keep it as a convenience function wrapping the other 3, but
it hardly seems worth it: the marker case just adds the overhead of
another funcall, whereas a significant proportion of the non-marker
calls in the codebase actually only care about the file name, so it is a
waste of effort to calculate the buffer position only to throw it away.)
WDYT?
>
> You can also remove `org-id-track-globally'. "org-id.el" is useless if
> it is set to nil anyway, since CUSTOM_ID does a better job in this
> case.
I think this would imply writing the ID database to ‘org-id-locations-file’
under certain circumstances without asking/letting the user approve this
action. Is that OK? (I am not bothered by it, FWIW).
If it’s not acceptable, perhaps this variable should be replaced by a
new defcustom ‘org-id-write-database’ which would control only the
writing of the DB to disk (but unlike the existing implementation would
not turn off the ID tracking code paths within the emacs session).
TIA,
--
Aaron Ecay
next prev parent reply other threads:[~2016-09-21 22:30 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-03 0:24 Feedback on changes to org-id Aaron Ecay
2016-09-03 8:25 ` Nicolas Goaziou
2016-09-21 22:28 ` Aaron Ecay [this message]
2016-09-22 2:50 ` Adam Porter
2016-09-22 7:16 ` Rasmus
2016-09-22 14:19 ` Adam Porter
2016-09-22 15:47 ` Aaron Ecay
2016-09-22 17:07 ` Adam Porter
2016-09-22 22:47 ` Nicolas Goaziou
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8760porioo.fsf@gmail.com \
--to=aaronecay@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=mail@nicolasgoaziou.fr \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.