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 fo
Aaron Ecay writes:
> Any change to the API would leave in place a compatibility alias for a
> significant period of time (at least one major version of Org), and
> there would be deprecation warnings to encourage package authors to
> switch to the new API. So packages like yours would continue t
Hi Adam,
2016ko irailak 22an, Adam Porter-ek idatzi zuen:
>
> Personally, I wish org-id-find would not be removed, because I use it in
> org-bookmark-heading, e.g.:
Any change to the API would leave in place a compatibility alias for a
significant period of time (at least one major version of Or
Rasmus writes:
> I didn't try your package, but from the description it simply allows one
> to use the standard Emacs bookmark system, correct? (I’m surprised it
> doesn’t work with org files out of the box).
Yes, that's right. I was surprised as well, that's why I did it. :)
> Such a featur
Adam Porter writes:
> Aaron Ecay 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 even
Aaron Ecay 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, sin
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
Hello,
Aaron Ecay writes:
> It’s an occasional project of mine to try to improve and refactor
> aspects of org’s code.
That's a very good idea, thanks.
BTW, please make sure that deprecation warnings all go into the same
location, namely "org-compat.el", instead of scattering them all over
the
Hello all,
It’s an occasional project of mine to try to improve and refactor
aspects of org’s code. I’ve been going through org-id recently. The
following issues came up that I would appreciate feedback on:
1. org-id is not loaded by default; it is supposed to be selected by the
user (see fo
