From: Matt Price <moptop99@gmail.com>
To: "Bruce D'Arcus" <bdarcus@gmail.com>,
org-mode-email <emacs-orgmode@gnu.org>
Subject: Re: [org-cite, oc-basic] configurable open-at-point, font-locking when json?
Date: Mon, 7 Jun 2021 22:20:52 -0400 [thread overview]
Message-ID: <CAN_Dec-xOXL2QCoMjT3G0ZjKGEE2XOLdaPoLWJgRLTMuKbomNw@mail.gmail.com> (raw)
In-Reply-To: <8735ttbcn4.fsf@nicolasgoaziou.fr>
[-- Attachment #1: Type: text/plain, Size: 2813 bytes --]
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
>
>
[-- Attachment #2: Type: text/html, Size: 3673 bytes --]
next prev parent reply other threads:[~2021-06-08 2:21 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 [this message]
2021-06-08 9:29 ` Nicolas Goaziou
2021-06-08 21:03 ` Matt Price
Reply instructions:
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAN_Dec-xOXL2QCoMjT3G0ZjKGEE2XOLdaPoLWJgRLTMuKbomNw@mail.gmail.com \
--to=moptop99@gmail.com \
--cc=bdarcus@gmail.com \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
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).