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