[org-cite] autoload oc processors?

[org-cite] autoload oc processors?

[Bruce D'Arcus]

[-- Attachment #1: Type: text/plain, Size: 59 bytes --]

Is there any reason not to autoload the processors?

Bruce

[-- Attachment #2: Type: text/html, Size: 127 bytes --]

Re: [org-cite] autoload oc processors?

[Nicolas Goaziou]

Hello,

"Bruce D'Arcus" <bdarcus@gmail.com> writes:

> Is there any reason not to autoload the processors?

I am not sure about what you mean. Could you elaborate?

Regards,
-- 
Nicolas Goaziou

Re: [org-cite] autoload oc processors?

[Bruce D'Arcus]

On Sun, Nov 28, 2021 at 5:19 PM Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:
>
> Hello,
>
> "Bruce D'Arcus" <bdarcus@gmail.com> writes:
>
> > Is there any reason not to autoload the processors?
>
> I am not sure about what you mean. Could you elaborate?

Primarily I am asking if there's a way to load the processor as needed
without a user explicitly having to do so.

I probably don't understand autoloading very well, but was thinking of
something like this:

;;;###autoload
(org-cite-register-processor 'oc-natbib ...

Bruce

Re: [org-cite] autoload oc processors?

[Timothy]

[-- Attachment #1: Type: text/plain, Size: 925 bytes --]

Hi Bruce,

> Primarily I am asking if there’s a way to load the processor as needed
> without a user explicitly having to do so.

This is actually a thought that occurred to me recently, and I’ve been
considering bringing up on the ML. Thanks for mentioning this.

A more sophisticated solution probably exists, but my thought was that if a cite
export keyword like this is seen:
┌────
│ #+cite_export: FORMAT ...
└────

and there is no known cite backend `FORMAT', then we could just try running
┌────
│ (require 'oc-FORMAT nil t)
└────

before complaining that there’s no cite backend FORMAT loaded.

This relies on consistent naming, but since that seems to hold pretty well so
far and failure to load just results in the current behaviour, I’m inclined to
think this would be a good change in terms of user experience.

All the best,
Timothy

Re: [org-cite] autoload oc processors?

[Nicolas Goaziou]

Hello,

Timothy <tecosaur@gmail.com> writes:

> A more sophisticated solution probably exists, but my thought was that if a cite
> export keyword like this is seen:
> ┌────
> │ #+cite_export: FORMAT ...
> └────
>
> and there is no known cite backend `FORMAT', then we could just try running
> ┌────
> │ (require 'oc-FORMAT nil t)
> └────
>
> before complaining that there’s no cite backend FORMAT loaded.
>
> This relies on consistent naming, but since that seems to hold pretty well so
> far and failure to load just results in the current behaviour, I’m inclined to
> think this would be a good change in terms of user experience.

OK. I implemented this on main branch. We'll see how it goes.

Thanks.

Regards,
-- 
Nicolas Goaziou

Re: [org-cite] autoload oc processors?

[Denis Maier]

Am 29.11.2021 um 23:48 schrieb Nicolas Goaziou:
> Hello,
> 
> Timothy <tecosaur@gmail.com> writes:
> 
>> A more sophisticated solution probably exists, but my thought was that if a cite
>> export keyword like this is seen:
>> ┌────
>> │ #+cite_export: FORMAT ...
>> └────
>>
>> and there is no known cite backend `FORMAT', then we could just try running
>> ┌────
>> │ (require 'oc-FORMAT nil t)
>> └────
>>
>> before complaining that there’s no cite backend FORMAT loaded.
>>
>> This relies on consistent naming, but since that seems to hold pretty well so
>> far and failure to load just results in the current behaviour, I’m inclined to
>> think this would be a good change in terms of user experience.
> 
> OK. I implemented this on main branch. We'll see how it goes.
> 

Thanks, that sounds like a good change!
Best,
Denis

Re: [org-cite] autoload oc processors?

[Nicolas Goaziou]

Hello,

"Bruce D'Arcus" <bdarcus@gmail.com> writes:

> I probably don't understand autoloading very well, but was thinking of
> something like this:
>
> ;;;###autoload
> (org-cite-register-processor 'oc-natbib ...

IIUC, this would register `natibib' processor for everyone whenever Org
is loaded. This may not be what you have in mind.

Regards,
-- 
Nicolas Goaziou