On Tue., Jun. 8, 2021, 5:29 a.m. Nicolas Goaziou, <m...@nicolasgoaziou.fr> wrote:
> Hello, > > Matt Price <mopto...@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
