From: Nicolas Goaziou <email@example.com>
To: Matt Price <firstname.lastname@example.org>
Cc: org-mode-email <email@example.com>,
Bruce D'Arcus <firstname.lastname@example.org>
Subject: Re: [org-cite, oc-basic] configurable open-at-point, font-locking when json?
Date: Tue, 08 Jun 2021 11:29:43 +0200 [thread overview]
Message-ID: <email@example.com> (raw)
In-Reply-To: <CAN_Dec-xOXL2QCoMjT3G0ZjKGEE2XOLdaPoLWJgRLTMuKbomNw@mail.gmail.com> (Matt Price's message of "Mon, 7 Jun 2021 22:20:52 -0400")
Matt Price <firstname.lastname@example.org> 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
> 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.
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
> 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
> 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?
next prev parent reply other threads:[~2021-06-08 9:48 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-07 16:53 [org-cite, oc-basic] configurable open-at-point, font-locking when json? Bruce D'Arcus
2021-06-07 18:46 ` Bruce D'Arcus
2021-06-07 21:14 ` Nicolas Goaziou
2021-06-07 21:27 ` Bruce D'Arcus
2021-06-07 21:57 ` Bruce D'Arcus
2021-06-08 9:33 ` Nicolas Goaziou
2021-06-08 11:36 ` Bruce D'Arcus
2021-06-08 13:07 ` Bruce D'Arcus
2021-06-08 20:25 ` Nicolas Goaziou
2021-06-08 21:02 ` Bruce D'Arcus
2021-06-09 11:32 ` Bruce D'Arcus
2021-06-09 15:46 ` Nicolas Goaziou
2021-06-08 2:20 ` Matt Price
2021-06-08 9:29 ` Nicolas Goaziou [this message]
2021-06-08 21:03 ` Matt Price
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).