On Tue., Jun. 8, 2021, 5:29 a.m. Nicolas Goaziou, <mail@nicolasgoaziou.fr>
wrote:

> Hello,
>
> Matt Price <moptop99@gmail.com> writes:
>
> > IIUC, the current architecture assigns responsibility for both *citation
> > export* and *in-buffer actions* to a processor shosen by the user (right
> > now, oc-cite, oc-natbib, or oc-csl).
>
> That's incorrect. The current architecture provides three entry points:
> `activate', `follow' and `export'. A processor can handle any, or all of
> these capabilities. For example, `natbib' processor doesn't provide any
> interface for `follow' or `activate'. OTOH `basic' provides the three of
> them.
>

Ah. Well then....

>
>
> Users can select a different processor for any of the capabilities
> listed above, independently on the others. So you don't have to change,
> for example, the processor responsible for fontification if you are
> swapping processor used for export.
>

Ahhhhh got it.

>
>
>
>
> > I guess this will become complicated once there are processors supporting
> > more exotic backends (e.g. Zotero via zotxt), but package managers could
> > handle that in readme's or perhaps with a single defcustom like, maybe,
> > ~org-zotxt-do-cite-setup~, or similar.
>
> I'm not sure to understand this, as I don't know what zotxt does
> exactly.
>

Well, I'm not sure it's relevant anymore, but zotxt provides a direct API
to the zotero database, and also an emacs library with functions for
querying and processing that API. All I really meant here is that of org
starts to support this kind of nonstandard backend (in which the
bibliography file isn't actually a file anymore), then the :activate and
:follow functions really will have to be different in buffers using that
backend.

>
> > I also think this will reduce code repetition across the 3 processors,
> and
> > generally simplify life for most users (though initial setup may be more
> > frequent.
> >
> > Have I understood correctly, and if so what do you think of this idea?
>
> Unless I'm mistaken, your idea is already implemented, isn't it?
>

Yup. Thanks for the very clear explanation and sorry for the noise.

Matt