From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: Feedback on changes to org-id Date: Fri, 23 Sep 2016 00:47:26 +0200 Message-ID: <87wpi3imbl.fsf@nicolasgoaziou.fr> References: <87fuphzv70.fsf@gmail.com> <87oa45z8y2.fsf@saiph.selenimh> <8760porioo.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:37775) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bnCmB-0005ge-Ru for emacs-orgmode@gnu.org; Thu, 22 Sep 2016 18:47:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bnCm9-0001l4-MY for emacs-orgmode@gnu.org; Thu, 22 Sep 2016 18:47:30 -0400 Received: from relay3-d.mail.gandi.net ([2001:4b98:c:538::195]:48965) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bnCm9-0001kG-GQ for emacs-orgmode@gnu.org; Thu, 22 Sep 2016 18:47:29 -0400 Received: from saiph (unknown [IPv6:2a03:a0a0:0:4301::b3c]) (Authenticated sender: mail@nicolasgoaziou.fr) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id CE34EA80BE for ; Fri, 23 Sep 2016 00:47:26 +0200 (CEST) In-Reply-To: <8760porioo.fsf@gmail.com> (Aaron Ecay's message of "Wed, 21 Sep 2016 23:28:55 +0100") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: Org-mode Hello, Aaron Ecay writes: > 2016ko irailak 3an, Nicolas Goaziou-ek idatzi zuen: > >> 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 I don't think these functions belong to the API. The seems more like internal functions, implemented before the "--" convention. > 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, This complicates the API for no real benefit. We ought to consider `org-id-find' as the sole entry point in "org-id.el". The rest is implementation details. More on this below. > 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.) In the code base, notwithstanding contrib/ and "org-id.el" itself, there are 4 calls to `org-id-find' without a marker. Half of them make use of the position (in org-capture and org-colview.el). If we add `org-id-find-id-in-file', there are two more calls. One of them actually require the position anyway (in ob-ref). I don't think 3 calls out of 6 is significant. If speed is an issue, we can add an optional argument to skip position (and marker) in the return value. E.g., (org-id-find ID &optional OUTPUT) where OUTPUT is either - nil : return value is the usual cons cell (file . position) - file : return value is the file, as a string - marker : return value is a marker. Again, I don't think we need 3 functions just for this. > I think this would imply writing the ID database to =E2=80=98org-id-locat= ions-file=E2=80=99 > under certain circumstances without asking/letting the user approve this > action. Is that OK? (I am not bothered by it, FWIW). > > If it=E2=80=99s not acceptable, perhaps this variable should be replaced = by a > new defcustom =E2=80=98org-id-write-database=E2=80=99 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). IMO the former is acceptable. If it happens to disturb some users, I guess we will fallback to the latter. Regards, --=20 Nicolas Goaziou