Ni Nicolas and Bruce,

I'm having trouble keeping up with these emails, let alone testing all these new features!  But this most recent response of yours, Nicolas, makes me wonder if it's worth raising a concern.

On Mon, Jun 7, 2021 at 5:15 PM Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:
Hello,

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

> Similar to my idea to have a configurable capf, could that function be
> configurable?
>
> A couple of people noted, for example, that the preferred choice would
> be that the actual document be opened. I actually got a PR for exactly
> this default behavior this past weekend, and bibtex-completion has a
> function that takes keys and does this. So would be great do something
> like:
>
> (setq org-cite-basic-open bibtex-completion-open-pdf)

If you want to use a different "follow" capability, you need to provide
a different processor instead of configuring this one.

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). 

In addition, it is more or less expected that some users will frequently switch back and forth between processors depending on whether they are exporting to latex or HTML (or something else, like ODT, I guess).

But these two features (in-buffer actions and eport) are functionally and logically distinct. The current architecture (if I've understood it right) means that in a non-infrequent use case, the in-buffer actions (and also fontification & overlays) will likely change back and forth rather quickly.But surely this is not what most users would want. Instead, they would likely want to fine-tune the in-buffer appearance and actions themselves.  Wouldn't it make sense to have a series of defcustoms, like, maybe, org-cite-open-function, org-cite-font-lock-function, and maybe others, which could be set by users on their own? Org-cite could supply some sensible defaults and advanced users could customize. 

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 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?

> Second, I completely lose font-locking when using json files. I know
> you have plans, Nicolas, to add json support, but even without that,
> shouldn't the citation be highlighted?

Could you provide an example?

Regards,
--
Nicolas Goaziou