From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id sCDGLOI8v2CnXgAAgWs5BA (envelope-from ) for ; Tue, 08 Jun 2021 11:48:18 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id wFL3J+I8v2AKKAAAB5/wlQ (envelope-from ) for ; Tue, 08 Jun 2021 09:48:18 +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 22ABE147AE for ; Tue, 8 Jun 2021 11:48:18 +0200 (CEST) Received: from localhost ([::1]:54356 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lqYLJ-0001sh-68 for larch@yhetil.org; Tue, 08 Jun 2021 05:48:17 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:49480) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lqY3S-0007xt-Kp for emacs-orgmode@gnu.org; Tue, 08 Jun 2021 05:29:50 -0400 Received: from relay4-d.mail.gandi.net ([217.70.183.196]:38365) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lqY3Q-0003cE-4W for emacs-orgmode@gnu.org; Tue, 08 Jun 2021 05:29:50 -0400 Received: (Authenticated sender: admin@nicolasgoaziou.fr) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 46B6FE0006; Tue, 8 Jun 2021 09:29:44 +0000 (UTC) From: Nicolas Goaziou To: Matt Price Subject: Re: [org-cite, oc-basic] configurable open-at-point, font-locking when json? References: <8735ttbcn4.fsf@nicolasgoaziou.fr> Mail-Followup-To: Matt Price , "Bruce D'Arcus" , org-mode-email Date: Tue, 08 Jun 2021 11:29:43 +0200 In-Reply-To: (Matt Price's message of "Mon, 7 Jun 2021 22:20:52 -0400") Message-ID: <8735tsk8l4.fsf@nicolasgoaziou.fr> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=217.70.183.196; envelope-from=mail@nicolasgoaziou.fr; helo=relay4-d.mail.gandi.net X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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: , Cc: org-mode-email , Bruce D'Arcus 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=1623145698; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc: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; bh=h1VChTTx+aZr0ja+WMBHP9defNhfUpvJgN/4x77fvAI=; b=p3C6j+T9wtcTyTqouN6cf7OvvkMyunWMeGn6yXj3iNI3cW5uDkSaWUhBbvXtVyWpnEv5Zt dvnMWaTtj+nKu0MdUhmZrGAtapo8Z8Dh4/IFbas2YufHiabSFZF+4Zr3kTroV82IdbJQ54 15PoZrr5PTjsBHsCQGayqR5gF9SulNSp3e3+k/NPgIdU958ZXCRcEDgfg2CfvMe5BpA4Ev kXqfeohI9VsCLJME+dmiTO4DtnidpF74DlhQYdPGg/pPb85vm+XMASbQov0rZY/u8iwwB8 hAkxhgP+8jNtJGcgQt7uBblR1v5sz3a1qYpiuerJ71Y1VOBbOCrb2K06dh2ogw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1623145698; a=rsa-sha256; cv=none; b=t1q3hVFvDXEoMp/KJbmXpiAUeWTpdet5B4LKhQQrD2ScuA2aYVeUr0sZIkI9NlkPYz4+gM Pev+YOUGLW6TwEVeK9ugCb21cKKCoyswdIq7qW1fucjGyjVYM5xDqQJjUPyHGGycJksc5O b0oggCBDQo2wnWGprhGCpbxVmCpFAlQommas2qKzWTfIQqVT2bIxc/tOiUaNSMqyKx3lZr JBno5zEKBeF7dreFKfTv2HpvyoMw5oBX0c8yaOCODPhYIg4VtzVZv5Q2kwnSQJBWMtyqKz Z1IdQjP7Llsi1b7wGjX/Ozs8Dfx20A68J+fomLU5wJwteUlYisPNgEbDE7Y8ZQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=none; 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: -1.42 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; 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: 22ABE147AE X-Spam-Score: -1.42 X-Migadu-Scanner: scn0.migadu.com X-TUID: yARwZnRZ2Awr 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. > 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