From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id ZDi+NEDUvmCYFgEAgWs5BA (envelope-from ) for ; Tue, 08 Jun 2021 04:21:52 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id cIJgL0DUvmDNYAAAbx9fmQ (envelope-from ) for ; Tue, 08 Jun 2021 02:21:52 +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 2842A25D2E for ; Tue, 8 Jun 2021 04:21:52 +0200 (CEST) Received: from localhost ([::1]:41298 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lqRNF-0008Ko-R1 for larch@yhetil.org; Mon, 07 Jun 2021 22:21:49 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:59648) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lqRMb-0008Ka-MN for emacs-orgmode@gnu.org; Mon, 07 Jun 2021 22:21:09 -0400 Received: from mail-ua1-x92a.google.com ([2607:f8b0:4864:20::92a]:46000) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lqRMZ-0007UD-0Y for emacs-orgmode@gnu.org; Mon, 07 Jun 2021 22:21:09 -0400 Received: by mail-ua1-x92a.google.com with SMTP id z13so5926434uai.12 for ; Mon, 07 Jun 2021 19:21:06 -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=RYit1FI93uCLyR8zXPtLbj3C8DZrBNDmK8keJ44FglA=; b=KxIgv7WyjsNgG77H7weR91oMHCgv72LzfxaQe8i+Iw65mimHxmnwZL59U3rCdrZRX7 e3nxqLTT0AXzbXFRu1Q8RlXNp2jt4eJ6lM3Q1i8Soi6VlBCcyXktMgUWfwIOwhO4bBjv dL7WDFa0l4E2idAmICb6bAcpOPmlFSreuLl3NT4qCSwdR94H/Mw8nk8Ihrefnkv4yZL4 tdPiTP6JfAGDqdB1MB12iqetcVp+RPyQZFYWETXwgo3L2IKAEVtOl0VKUMJxmuo+DrdB uJpiOAFbgQ1oOJtN+kUh6xoSqwTSpDMAmMi5KyPrkT/aWh9lZEX6TfxReqVJZKuBs4W6 nXtg== 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=RYit1FI93uCLyR8zXPtLbj3C8DZrBNDmK8keJ44FglA=; b=rIKPFSYpogvF8yTK+KV3f2Bf1AiDTSDJN6y/q20Wrx5eZnh/UuOtRG+ULIH+GMNfX6 WU2nIvn5l9zGcCV2p8gFgGvYtnerG32MATY9dd4fzng3K/GeN/U+17XTUOdpUDPJA3ky F0YhqbwYIGFFmXt8339TDFIojTWWZWCWjT5eykETe+lPNLvZQeBMzab56olzocXCYYyS D/DQfaq8uhtqtq5foYIoQH7Qquy/HTBLuhP66S+h0DtljPKxg4o9YmObZEMdjiKaR9Cc QtZ9+//CNbUd0rp4gqMN4Zp74r8tV3Pv3lSiBY3uW6+7CdPZFbYaJwrqwIg/7p2acUl3 qEbQ== X-Gm-Message-State: AOAM530ozJh5kxdDJjw39UP/Z2q0izPyHDLsVAEgHYx9BtDNMCaCZD16 jzw9NH7Hv7YjfbIPY5I8hr+yhGumHQU84Gf1jpg= X-Google-Smtp-Source: ABdhPJw83WY2s/2mlRKO6e5yBoZbp9Rw589Md/carKwnVd/hOhkx2Fv1TZzhTphYgOVLt0XiX+5cVTPE+dXBOPDTRvo= X-Received: by 2002:a05:6122:1792:: with SMTP id o18mr10077266vkf.21.1623118865350; Mon, 07 Jun 2021 19:21:05 -0700 (PDT) MIME-Version: 1.0 References: <8735ttbcn4.fsf@nicolasgoaziou.fr> In-Reply-To: <8735ttbcn4.fsf@nicolasgoaziou.fr> From: Matt Price Date: Mon, 7 Jun 2021 22:20:52 -0400 Message-ID: Subject: Re: [org-cite, oc-basic] configurable open-at-point, font-locking when json? To: "Bruce D'Arcus" , org-mode-email Content-Type: multipart/alternative; boundary="00000000000065c61d05c437cfdc" Received-SPF: pass client-ip=2607:f8b0:4864:20::92a; envelope-from=moptop99@gmail.com; helo=mail-ua1-x92a.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=1623118912; 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=RYit1FI93uCLyR8zXPtLbj3C8DZrBNDmK8keJ44FglA=; b=ucvvc5sfPg7dunKxo6i6Ao0NmHP/nEi1By+FhYtpn9Lo9rzYYlgWb3aBQvoBImTZTAMJh1 ErpudIiFDU+cv3v7uSdYl/OOERG2YGIXu4Xdlg8+AmdydO2EDTDngzXWUtRsvv5XLW5ooS oGEO5tiMTQEKEXXY39M9CwsiRIKwqP+E4cpkywXItcp/TF6vO6ll9jgHFHM7hNQDVZOPZo BFA3KrBJX+r1Kjfc4TerrNQZWp5O1SMb5M3uLiUoIvAFUybIVXEov0AhuwU1seff4sGkRp FFQPl2BpBTdrzx1sJDhNMPcMsHL5mAoxPeizaNSUkaBnT8rEWIle9dbQ5AC0pg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1623118912; a=rsa-sha256; cv=none; b=OOl0v8l1dML9tAf5dyOf+KB2c1fpSZ+3SakVstM4URX6u65enEPJV8smIiHXQMDhxxTJCA zaosNqp5FYTqpybD7T9cppETR9bj1arUSuy0cB6/ZTiv8Wdkt6jbKE8qfBouAAVZVjiRht bFuYOZRpIMLaiiYQskNj/JmBsV36Riq5trpNIvb6zyDA/YjS9c+cFlAB4itUoin1+oqZDu Nrwu68frEKI9CgIvmdGek5Mv7sAB3fzlrB8MBTCmShsT8/QN3X6pmC6mh2jyDhboSQrbpp qx/lCYfaFz/zTaHr9mVeDkyKxF2h8BXZ1sjtA/RpI6W0wHJ1SEEAc7qXE27WCw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=KxIgv7Wy; 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=KxIgv7Wy; 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: 2842A25D2E X-Spam-Score: -2.12 X-Migadu-Scanner: scn1.migadu.com X-TUID: HQJhEWgx4BUK --00000000000065c61d05c437cfdc Content-Type: text/plain; charset="UTF-8" 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 wrote: > Hello, > > "Bruce D'Arcus" 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 > > --00000000000065c61d05c437cfdc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ni Nicolas and Bruce,

I'= m having trouble keeping up with these emails, let alone testing all these = new features!=C2=A0 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 P= M Nicolas Goaziou <mail@nicola= sgoaziou.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 p= rovide
a different processor instead of configuring this one.

IIUC, the current architecture assigns responsibility for b= oth *citation export* and *in-buffer actions* to a processor shosen by the = user (right now, oc-cite, oc-natbib, or oc-csl).=C2=A0

<= /div>
In addition, it is more or less expected that some users will fre= quently 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 epo= rt) are functionally and logically distinct. The current architecture (if I= 've understood it right) means that in a non-infrequent use case, the i= n-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 appearanc= e and actions themselves.=C2=A0 Wouldn't it make sense to have a series= of defcustoms, like, maybe, org-cite-open-function, org-cite-font-lock-fun= ction, and maybe others, which could be set by users on their own? Org-cite= could supply some sensible defaults and advanced users could customize.=C2= =A0

I guess this will become complicated once= there are processors supporting more exotic backends (e.g. Zotero via zotx= t), 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 t= he 3 processors, and generally simplify life for most users (though initial= setup may be more frequent.

Have I understood cor= rectly, 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

--00000000000065c61d05c437cfdc--