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

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

[Bruce D'Arcus]

I'm kind of losing track of details, but two things:

First, the current oc-basic has a "follow" function that if point is
over a citation-reference (key), and one does "M-x org-open-at-point",
the bibtex entry is opened.

Very cool!

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)

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?

Bruce

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

[Bruce D'Arcus]

On Mon, Jun 7, 2021 at 12:53 PM Bruce D'Arcus <bdarcus@gmail.com> wrote:

> ... would be great do something
> like:
>
> (setq org-cite-basic-open bibtex-completion-open-pdf)

I guess that raises a question for me about what code goes where.

Maybe instead have it set in oc.el?

(setq org-cite-open 'bibtex-completion-open-pdf)

Bruce


Bruce

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

[Nicolas Goaziou]

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.

> 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

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

[Bruce D'Arcus]

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

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

OIC.

So would it be so simple as doing something like this, to use the
bibtex-completion-open function instead?

(org-cite-register-processor 'basic
  :follow #'bibtex-completion-open)

As in, that just tells what function to use for at-point?

If yes, that definitely works!

I've been a bit slow wrapping my head around the difference between
follow and activate, but I think it's starting to become more clear.

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

I'm sorry; you're going to kill me.

In trying to reproduce it just now, I can't.

So I guess you can ignore this too.

Bruce

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

[Bruce D'Arcus]

On Mon, Jun 7, 2021 at 5:27 PM Bruce D'Arcus <bdarcus@gmail.com> wrote:

> So would it be so simple as doing something like this, to use the
> bibtex-completion-open function instead?
>
> (org-cite-register-processor 'basic
>   :follow #'bibtex-completion-open)
>
> As in, that just tells what function to use for at-point?

... or rather, one would have to write additional code to accompany
that function?

LIke a 'oc-bibtex-completion-follow'?

Bruce

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

[Nicolas Goaziou]

Hello,

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

> So would it be so simple as doing something like this, to use the
> bibtex-completion-open function instead?
>
> (org-cite-register-processor 'basic
>   :follow #'bibtex-completion-open)
>
> As in, that just tells what function to use for at-point?
>
> If yes, that definitely works!

It does, but you're overriding `basic' processor. You could as well
define your own processor

  (org-cite-register-processor 'bibtex
    :follow #'bibtex-completion-open)

and use it with

  (setq org-cite-follow-processor 'bibtex)

> I've been a bit slow wrapping my head around the difference between
> follow and activate, but I think it's starting to become more clear.

Follow is what happens when you use C-o on a citation. Activate is run
in the background during font-lock.

Regards,
-- 
Nicolas Goaziou

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

[Bruce D'Arcus]

On Tue, Jun 8, 2021 at 5:33 AM Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:
>
> Hello,
>
> "Bruce D'Arcus" <bdarcus@gmail.com> writes:
>
> > So would it be so simple as doing something like this, to use the
> > bibtex-completion-open function instead?
> >
> > (org-cite-register-processor 'basic
> >   :follow #'bibtex-completion-open)
> >
> > As in, that just tells what function to use for at-point?
> >
> > If yes, that definitely works!
>
> It does, but you're overriding `basic' processor. You could as well
> define your own processor
>
>   (org-cite-register-processor 'bibtex
>     :follow #'bibtex-completion-open)
>
> and use it with
>
>   (setq org-cite-follow-processor 'bibtex)
>
> > I've been a bit slow wrapping my head around the difference between
> > follow and activate, but I think it's starting to become more clear.
>
> Follow is what happens when you use C-o on a citation. Activate is run
> in the background during font-lock.

That's a very clear explanation!

So I'm trying to get this working now.

Here's what I want:

- "basic" font-locking
- bibtex-completion-open-any for C-o

If I understand correctly, the below minimal config should work, but
does not; as in, no font-locking, and C-o returns a "no link found".

What am I doing wrong?

(require 'oc-basic)
(require 'bibtex-completion)

(org-cite-register-processor 'bibtex
    :follow #'bibtex-completion-open-any)

(setq org-cite-follow-processor 'bibtex)
(setq org-cite-activate-processor 'basic)

Bruce

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

[Bruce D'Arcus]

On Tue, Jun 8, 2021 at 7:36 AM Bruce D'Arcus <bdarcus@gmail.com> wrote:

> (org-cite-register-processor 'bibtex
>     :follow #'bibtex-completion-open-any)

Actually, looking at the docstrings, I don't think this will work as
is, as the follow processor "accepts two arguments, the citation or
citation reference object at point", while the bibtex-completion
functions take a list of keys.

So I guess for that I'd need a little wrapper to call that function.

Still, I'm confused why the basic font-locking doesn't work in this case.

Bruce

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

[Nicolas Goaziou]

Hello,

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

> On Tue, Jun 8, 2021 at 7:36 AM Bruce D'Arcus <bdarcus@gmail.com> wrote:
>
>> (org-cite-register-processor 'bibtex
>>     :follow #'bibtex-completion-open-any)
>
> Actually, looking at the docstrings, I don't think this will work as
> is, as the follow processor "accepts two arguments, the citation or
> citation reference object at point", while the bibtex-completion
> functions take a list of keys.
>
> So I guess for that I'd need a little wrapper to call that function.

Indeed.

> Still, I'm confused why the basic font-locking doesn't work in this case.

I know it is not terribly useful but… it works here. For example, if no
bibliography is defined, all cite keys are red (error face).

Regards,
-- 
Nicolas Goaziou

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

[Bruce D'Arcus]

[-- Attachment #1: Type: text/plain, Size: 457 bytes --]

On Tue, Jun 8, 2021 at 4:25 PM Nicolas Goaziou <mail@nicolasgoaziou.fr>
wrote:

> > Still, I'm confused why the basic font-locking doesn't work in this
case.
>
> I know it is not terribly useful but… it works here. For example, if no
> bibliography is defined, all cite keys are red (error face).

Actually that is useful; it confirms I basically understand this, but
there's something else wrong with my config or something.

Thanks,
Bruce

[-- Attachment #2: Type: text/html, Size: 635 bytes --]

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

[Bruce D'Arcus]

On Tue, Jun 8, 2021 at 4:25 PM Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:
>
> Hello,
>
> "Bruce D'Arcus" <bdarcus@gmail.com> writes:
>
> > On Tue, Jun 8, 2021 at 7:36 AM Bruce D'Arcus <bdarcus@gmail.com> wrote:
> >
> >> (org-cite-register-processor 'bibtex
> >>     :follow #'bibtex-completion-open-any)
> >
> > Actually, looking at the docstrings, I don't think this will work as
> > is, as the follow processor "accepts two arguments, the citation or
> > citation reference object at point", while the bibtex-completion
> > functions take a list of keys.
> >
> > So I guess for that I'd need a little wrapper to call that function.
>
> Indeed.

Not a big deal, but I'll ask :-)

Given how common existing functions are that take a list of keys, WDYT
about adding something like a `org-cite-get-references-keys` helper
function, to parallel `org-cite-get-references`?

So in this case one could do:

(bibtex-completion-open-any (org-cite-get-references-keys datum)))

Bruce

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

[Nicolas Goaziou]

Hello,

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

> Given how common existing functions are that take a list of keys, WDYT
> about adding something like a `org-cite-get-references-keys` helper
> function, to parallel `org-cite-get-references`?
>
> So in this case one could do:
>
> (bibtex-completion-open-any (org-cite-get-references-keys datum)))

Fair enough. I added an optional KEYS-ONLY argument to
`org-cite-get-references' doing just that.

Regards,
-- 
Nicolas Goaziou

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

[Matt Price]

[-- 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 --]

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

[Nicolas Goaziou]

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

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

[Matt Price]

[-- Attachment #1: Type: text/plain, Size: 2138 bytes --]

On Tue., Jun. 8, 2021, 5:29 a.m. Nicolas Goaziou, <mail@nicolasgoaziou.fr>
wrote:

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

Ah. Well then....

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

Ahhhhh got it.

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

Well, I'm not sure it's relevant anymore, but zotxt provides a direct API
to the zotero database, and also an emacs library with functions for
querying and processing that API. All I really meant here is that of org
starts to support this kind of nonstandard backend (in which the
bibliography file isn't actually a file anymore), then the :activate and
:follow functions really will have to be different in buffers using that
backend.

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

Yup. Thanks for the very clear explanation and sorry for the noise.

Matt

[-- Attachment #2: Type: text/html, Size: 3449 bytes --]