Re: [org-cite, oc-basic] configurable open-at-point, font-locking when json?

[Nicolas Goaziou <mail@nicolasgoaziou.fr>]

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.

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

Indeed.

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

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.

There are already defcustoms for that: `org-cite-activate-processor',
`org-cite-export-processors', `org-cite-follow-processor'. The only
difference with your proposal is that you currently feed them with
a processor name instead of a function.

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

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

Regards,
-- 
Nicolas Goaziou