From mboxrd@z Thu Jan  1 00:00:00 1970
From: Adam Porter <adam@alphapapa.net>
Subject: Re: Feedback on changes to org-id
Date: Wed, 21 Sep 2016 21:50:17 -0500
Message-ID: <87d1jwejh2.fsf@alphapapa.net>
References: <87fuphzv70.fsf@gmail.com> <87oa45z8y2.fsf@saiph.selenimh>
	<8760porioo.fsf@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain
Return-path: <emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org>
Received: from eggs.gnu.org ([2001:4830:134:3::10]:37786)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <geo-emacs-orgmode@m.gmane.org>) id 1bmu67-0000Wo-Jn
	for emacs-orgmode@gnu.org; Wed, 21 Sep 2016 22:50:52 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <geo-emacs-orgmode@m.gmane.org>) id 1bmu62-0001I7-SD
	for emacs-orgmode@gnu.org; Wed, 21 Sep 2016 22:50:51 -0400
Received: from [195.159.176.226] (port=53820 helo=blaine.gmane.org)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <geo-emacs-orgmode@m.gmane.org>) id 1bmu62-0001Gh-M5
	for emacs-orgmode@gnu.org; Wed, 21 Sep 2016 22:50:46 -0400
Received: from list by blaine.gmane.org with local (Exim 4.84_2)
	(envelope-from <geo-emacs-orgmode@m.gmane.org>) id 1bmu5k-00056N-J4
	for emacs-orgmode@gnu.org; Thu, 22 Sep 2016 04:50:28 +0200
List-Id: "General discussions about Org-mode." <emacs-orgmode.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-orgmode>,
	<mailto:emacs-orgmode-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/emacs-orgmode/>
List-Post: <mailto:emacs-orgmode@gnu.org>
List-Help: <mailto:emacs-orgmode-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-orgmode>,
	<mailto:emacs-orgmode-request@gnu.org?subject=subscribe>
Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org
Sender: "Emacs-orgmode"
	<emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org>
To: emacs-orgmode@gnu.org

Aaron Ecay <aaronecay@gmail.com> writes:

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

Personally, I wish org-id-find would not be removed, because I use it in
org-bookmark-heading, e.g.:

https://github.com/alphapapa/org-bookmark-heading/blob/master/org-bookmark-heading.el#L126

On the other hand, maybe this is a good time to see about getting
org-bookmark-heading into org itself, in which case whoever changes the
API would be responsible for updating it... ;)  WDYT?