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