"Rick Lupton" writes:
> I have been using the simpler version using advice (without my patch).
>
> On reflection this seems ok to me -- I don't think there's really any need
> for my proposed patch, unless it turns out in future that there are multiple
> packages like org-roam that need to supp
I have been using the simpler version using advice (without my patch).
On reflection this seems ok to me -- I don't think there's really any need for
my proposed patch, unless it turns out in future that there are multiple
packages like org-roam that need to supply org-id-finding abilities in a
Ihor Radchenko writes:
> Also, before we merge your patch, may I know if you discussed this
> change with org-roam developers? If they do not want to use the proposed
> hook, there is no reason to add it to Org mode.
It has been over a month since the last message in this thread.
May I know if t
"Rick Lupton" writes:
> The point is that I was thinking org-roam should advise/modify/hook the
> specific function `org-id-find' [to find ids in its database] but NOT the
> more general `(org-link-get-parameter "id" :follow)' [because `org-id-open'
> has a lot of extra logic for search-string
Thanks, I hadn't understood the significance of named functions vs variables
for advice. But now I realise this is not solving the same problem as the
original patch.
The point is that I was thinking org-roam should advise/modify/hook the
specific function `org-id-find' [to find ids in its dat
"Rick Lupton" writes:
> On Wed, 13 Mar 2024, at 12:30 PM, Ihor Radchenko wrote:
>> I think that we can do it simpler. [...]
>> The idea is to use Emacs' advice machinery to allow third-party code
>> alter the functions stored in link parameters.
>
> I was avoiding this because I thought it was on
On Wed, 13 Mar 2024, at 12:30 PM, Ihor Radchenko wrote:
> I think that we can do it simpler. [...]
> The idea is to use Emacs' advice machinery to allow third-party code
> alter the functions stored in link parameters.
I was avoiding this because I thought it was only recommended (in the elisp
ma
"Rick Lupton" writes:
> Since updating the org-id code [1] to use the standard org-link registered
> functions instead of hard-coding org-id opening, I have a problem using
> org-roam.
>
> org-roam overwrites the :follow function for "id" links from the build-in
> `org-id-open' to its own `org
Hi all,
Since updating the org-id code [1] to use the standard org-link registered
functions instead of hard-coding org-id opening, I have a problem using
org-roam.
org-roam overwrites the :follow function for "id" links from the build-in
`org-id-open' to its own `org-roam-id-open'
(https://g