From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id 0IMgE2Hbv2D9DgAAgWs5BA (envelope-from ) for ; Tue, 08 Jun 2021 23:04:33 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id eMVtDmHbv2BqdgAAB5/wlQ (envelope-from ) for ; Tue, 08 Jun 2021 21:04:33 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 9AC5620E63 for ; Tue, 8 Jun 2021 23:04:32 +0200 (CEST) Received: from localhost ([::1]:34780 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lqitj-0004Q8-Ih for larch@yhetil.org; Tue, 08 Jun 2021 17:04:31 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:60366) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lqisx-0004OB-Jv for emacs-orgmode@gnu.org; Tue, 08 Jun 2021 17:03:43 -0400 Received: from mail-vs1-xe2c.google.com ([2607:f8b0:4864:20::e2c]:39899) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lqiss-0002h3-Qq for emacs-orgmode@gnu.org; Tue, 08 Jun 2021 17:03:43 -0400 Received: by mail-vs1-xe2c.google.com with SMTP id z206so11697012vsz.6 for ; Tue, 08 Jun 2021 14:03:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=0drCVgr1C2orvS1kH99nXVSC+r8NIG/iQc4MSkeQyoA=; b=sHgCdGCl+udxPYT+KhjV1nDAkKhGnzJk/hF+GEpvPNeEVr3sFwycNhcIb/JTdhaw1G tjvY7Zq07F070pDnNqhQyDuqC1hQXGQNMaicz3ndyHmR7YlhnxqQbXPYJjlJxnmE4SCc 80ufNt0Uk0Qk+/JidBJMnsTycE22WDRr5L6qu5FL4VGW62o9rcHuiM/KZwOOr8wYRMUj ano2HRq+BdV0YffNsuMrFUb9gqyog9X5c653w8S0c5jsFsBRxDwCU6nCO7uaahVNwd6R veUbZfHpJr/kNTMp3Y8E5d268B3kq/8LrRdTH7tc3uaJzqLjBynXeDyX3loCzKBQn77L l1lQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=0drCVgr1C2orvS1kH99nXVSC+r8NIG/iQc4MSkeQyoA=; b=Hjr36JJt9X34NpWX9eS5oeJ12TZEc38rqQEHmhFUrzTvmonWAQ+Ej4nPLnQfHLscxt 1oy7JZ1iytBeqA7/vmk6jnau2DoHRyA8Fjvm8ZEKfGVPwM6AngtwZeilJViA3xdgSOAu nrpY1M0OumW47vV5MHv52d2a+kp/eLvMUxDIT0Rym6EdByTXiQRDXOTDX1hvetc6hkT7 dcMP/b65vUhs4yIZ/E4nenmx8XxNNn2DA+t3E5SQHtNohm0SLeojUfpUMNejogwkv6Dx DtnJTA35NUHMKqm/gI8vQHhEhhoFMFhFG8hTTpT5e36fdfbtssmE2Gh0XFvP57xcLb9I BHFw== X-Gm-Message-State: AOAM533QrqYk1keBOwhrPUUWNVoFPRbA7ONicpewMvWWYaq0eN/USZon AAg8gdWiqaJWrrl1boukLhVVbapqxvhjBadlWK0= X-Google-Smtp-Source: ABdhPJwQM14K1wjuWkFGwkcw1gVOwu3vJUV3ajbspY77qEQskWcIVcSmw4pre1ZkyKnAjGW6XyO9rnXOySEe3il1H28= X-Received: by 2002:a67:eb85:: with SMTP id e5mr2359437vso.16.1623186217771; Tue, 08 Jun 2021 14:03:37 -0700 (PDT) MIME-Version: 1.0 References: <8735ttbcn4.fsf@nicolasgoaziou.fr> <8735tsk8l4.fsf@nicolasgoaziou.fr> In-Reply-To: <8735tsk8l4.fsf@nicolasgoaziou.fr> From: Matt Price Date: Tue, 8 Jun 2021 17:03:26 -0400 Message-ID: Subject: Re: [org-cite, oc-basic] configurable open-at-point, font-locking when json? To: Matt Price , "Bruce D'Arcus" , org-mode-email Content-Type: multipart/alternative; boundary="000000000000ea251005c4477d61" Received-SPF: pass client-ip=2607:f8b0:4864:20::e2c; envelope-from=moptop99@gmail.com; helo=mail-vs1-xe2c.google.com X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1623186272; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=0drCVgr1C2orvS1kH99nXVSC+r8NIG/iQc4MSkeQyoA=; b=ujBoyesJ7na4cKXKRbJhGCuZRuPmIGnZBXE1w0WHaCpdlpyWcmMO3/joOqcjXOv+iJvqBc T139Ity2nRqd7w0gpj8ttGfK2Q+eCSZXsOb7ujgyCMyLJJsoXYFLpeU8fNk191TzAZA0tg mKN6ZpwHTjvJC1ZMds1lx0JhrmIaT6jkqwnsp0tAxtZDos53EhO/4bRY1S4ebunW6539ez eFGQTtGiPFb0i6ZNHvMKJUKupXZJKR15tTA3JilpPz2ElWnXIrG6Sbv49RuX8nqezOb3dS ETGGI9bVhqfNzBEFf+fvcwykgUWx64ywC22yP6xU5GwRqpU3OuIQ90jT/8R6kA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1623186272; a=rsa-sha256; cv=none; b=aeulK52+h/2nFHfaJNdlIOvS7PgdR9k9jHpzNbHYRe6TxRbuz89/FoB5fNrzgDkBO3tqTI n8rKT+fhT329HYfBXUdwxhCn7ZtZA5mjYo6AsAQ9lFc41xUgBx/4RxRZ7ROAIsOjAXK1Qp g4cWXY044kxSTi14ylLD2U9b+PHkpKmw+lrn8Krh2EoSp3nOBAVcbZrCFwVswA6M+TgF9E /udjAwXXQvOmvunkJVy5cIHRHwvE8Oy33UhXFJ7d/9p5bv+yTt5surVJcPAO0lpN7/iBwi MgbuHCk2Ljt/UUgfDduktd1E8h5uPUfDvtKGBW0/wfMtiQYMGsDFIip46LKTeQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=sHgCdGCl; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Migadu-Spam-Score: -2.12 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=sHgCdGCl; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Migadu-Queue-Id: 9AC5620E63 X-Spam-Score: -2.12 X-Migadu-Scanner: scn0.migadu.com X-TUID: c12kY+IUpyho --000000000000ea251005c4477d61 Content-Type: text/plain; charset="UTF-8" On Tue., Jun. 8, 2021, 5:29 a.m. Nicolas Goaziou, wrote: > Hello, > > Matt Price 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 --000000000000ea251005c4477d61 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


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

Matt Price <moptop99@gmail.com> writes:

> IIUC, the current architecture assigns responsibility for both *citati= on
> export* and *in-buffer actions* to a processor shosen by the user (rig= ht
> 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.=C2=A0=C2=A0



> I guess this will become complicated once there are processors support= ing
> more exotic backends (e.g. Zotero via zotxt), but package managers cou= ld
> handle that in readme's or perhaps with a single defcustom like, m= aybe,
> ~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 provi= des a direct API to the zotero database, and also an emacs library with fun= ctions for=C2=A0 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 :activa= te and :follow functions really will have to be different in buffers using = that backend.=C2=A0

> I also think this will reduce code repetition across the 3 processors,= and
> generally simplify life for most users (though initial setup may be mo= re
> 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
--000000000000ea251005c4477d61--