all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* [org-cite, oc-basic] configurable open-at-point, font-locking when json?
@ 2021-06-07 16:53 Bruce D'Arcus
  2021-06-07 18:46 ` Bruce D'Arcus
  2021-06-07 21:14 ` Nicolas Goaziou
  0 siblings, 2 replies; 15+ messages in thread
From: Bruce D'Arcus @ 2021-06-07 16:53 UTC (permalink / raw)
  To: org-mode-email

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


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [org-cite, oc-basic] configurable open-at-point, font-locking when json?
  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
  1 sibling, 0 replies; 15+ messages in thread
From: Bruce D'Arcus @ 2021-06-07 18:46 UTC (permalink / raw)
  To: org-mode-email

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


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [org-cite, oc-basic] configurable open-at-point, font-locking when json?
  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-08  2:20   ` Matt Price
  1 sibling, 2 replies; 15+ messages in thread
From: Nicolas Goaziou @ 2021-06-07 21:14 UTC (permalink / raw)
  To: Bruce D'Arcus; +Cc: org-mode-email

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


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [org-cite, oc-basic] configurable open-at-point, font-locking when json?
  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  2:20   ` Matt Price
  1 sibling, 2 replies; 15+ messages in thread
From: Bruce D'Arcus @ 2021-06-07 21:27 UTC (permalink / raw)
  To: Bruce D'Arcus, org-mode-email

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


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [org-cite, oc-basic] configurable open-at-point, font-locking when json?
  2021-06-07 21:27   ` Bruce D'Arcus
@ 2021-06-07 21:57     ` Bruce D'Arcus
  2021-06-08  9:33     ` Nicolas Goaziou
  1 sibling, 0 replies; 15+ messages in thread
From: Bruce D'Arcus @ 2021-06-07 21:57 UTC (permalink / raw)
  To: Bruce D'Arcus, org-mode-email

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


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [org-cite, oc-basic] configurable open-at-point, font-locking when json?
  2021-06-07 21:14 ` Nicolas Goaziou
  2021-06-07 21:27   ` Bruce D'Arcus
@ 2021-06-08  2:20   ` Matt Price
  2021-06-08  9:29     ` Nicolas Goaziou
  1 sibling, 1 reply; 15+ messages in thread
From: Matt Price @ 2021-06-08  2:20 UTC (permalink / raw)
  To: Bruce D'Arcus, org-mode-email

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [org-cite, oc-basic] configurable open-at-point, font-locking when json?
  2021-06-08  2:20   ` Matt Price
@ 2021-06-08  9:29     ` Nicolas Goaziou
  2021-06-08 21:03       ` Matt Price
  0 siblings, 1 reply; 15+ messages in thread
From: Nicolas Goaziou @ 2021-06-08  9:29 UTC (permalink / raw)
  To: Matt Price; +Cc: org-mode-email, Bruce D'Arcus

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


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [org-cite, oc-basic] configurable open-at-point, font-locking when json?
  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
  1 sibling, 1 reply; 15+ messages in thread
From: Nicolas Goaziou @ 2021-06-08  9:33 UTC (permalink / raw)
  To: Bruce D'Arcus; +Cc: org-mode-email

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


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [org-cite, oc-basic] configurable open-at-point, font-locking when json?
  2021-06-08  9:33     ` Nicolas Goaziou
@ 2021-06-08 11:36       ` Bruce D'Arcus
  2021-06-08 13:07         ` Bruce D'Arcus
  0 siblings, 1 reply; 15+ messages in thread
From: Bruce D'Arcus @ 2021-06-08 11:36 UTC (permalink / raw)
  To: Bruce D'Arcus, org-mode-email

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


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [org-cite, oc-basic] configurable open-at-point, font-locking when json?
  2021-06-08 11:36       ` Bruce D'Arcus
@ 2021-06-08 13:07         ` Bruce D'Arcus
  2021-06-08 20:25           ` Nicolas Goaziou
  0 siblings, 1 reply; 15+ messages in thread
From: Bruce D'Arcus @ 2021-06-08 13:07 UTC (permalink / raw)
  To: org-mode-email

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


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [org-cite, oc-basic] configurable open-at-point, font-locking when json?
  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
  0 siblings, 2 replies; 15+ messages in thread
From: Nicolas Goaziou @ 2021-06-08 20:25 UTC (permalink / raw)
  To: Bruce D'Arcus; +Cc: org-mode-email

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


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [org-cite, oc-basic] configurable open-at-point, font-locking when json?
  2021-06-08 20:25           ` Nicolas Goaziou
@ 2021-06-08 21:02             ` Bruce D'Arcus
  2021-06-09 11:32             ` Bruce D'Arcus
  1 sibling, 0 replies; 15+ messages in thread
From: Bruce D'Arcus @ 2021-06-08 21:02 UTC (permalink / raw)
  To: org-mode-email

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [org-cite, oc-basic] configurable open-at-point, font-locking when json?
  2021-06-08  9:29     ` Nicolas Goaziou
@ 2021-06-08 21:03       ` Matt Price
  0 siblings, 0 replies; 15+ messages in thread
From: Matt Price @ 2021-06-08 21:03 UTC (permalink / raw)
  To: Matt Price, Bruce D'Arcus, org-mode-email

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [org-cite, oc-basic] configurable open-at-point, font-locking when json?
  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
  1 sibling, 1 reply; 15+ messages in thread
From: Bruce D'Arcus @ 2021-06-09 11:32 UTC (permalink / raw)
  To: org-mode-email

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


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [org-cite, oc-basic] configurable open-at-point, font-locking when json?
  2021-06-09 11:32             ` Bruce D'Arcus
@ 2021-06-09 15:46               ` Nicolas Goaziou
  0 siblings, 0 replies; 15+ messages in thread
From: Nicolas Goaziou @ 2021-06-09 15:46 UTC (permalink / raw)
  To: Bruce D'Arcus; +Cc: org-mode-email

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


^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2021-06-09 15:48 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
2021-06-08 21:03       ` Matt Price

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.