From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:8:6d80::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id QC9sMycwfGAUGgAAgWs5BA (envelope-from ) for ; Sun, 18 Apr 2021 15:12:07 +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 0I/zLicwfGDbIQAAB5/wlQ (envelope-from ) for ; Sun, 18 Apr 2021 13:12:07 +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 479F4222C2 for ; Sun, 18 Apr 2021 15:12:07 +0200 (CEST) Received: from localhost ([::1]:47788 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lY7Da-0000Sc-0R for larch@yhetil.org; Sun, 18 Apr 2021 09:12:06 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:44132) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lY7Cm-0000QA-DO for emacs-orgmode@gnu.org; Sun, 18 Apr 2021 09:11:16 -0400 Received: from relay9-d.mail.gandi.net ([217.70.183.199]:60609) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lY7Cj-00023J-IW for emacs-orgmode@gnu.org; Sun, 18 Apr 2021 09:11:15 -0400 X-Originating-IP: 185.131.40.67 Received: from localhost (40-67.ipv4.commingeshautdebit.fr [185.131.40.67]) (Authenticated sender: admin@nicolasgoaziou.fr) by relay9-d.mail.gandi.net (Postfix) with ESMTPSA id DE0D6FF804; Sun, 18 Apr 2021 13:11:08 +0000 (UTC) From: Nicolas Goaziou To: =?utf-8?Q?Andr=C3=A1s?= Simonyi Subject: Re: wip-cite status question and feedback References: <874ktu8gr9.fsf@nicolasgoaziou.fr> <87mu5xpm4x.fsf@gnu.org> <87img81ad7.fsf@gnu.org> <20210324182751.GA8721@atlantis> <87czuzprmh.fsf@nicolasgoaziou.fr> Mail-Followup-To: =?utf-8?Q?Andr=C3=A1s?= Simonyi , "Bruce D'Arcus" , "emacs-orgmode@gnu.org" Date: Sun, 18 Apr 2021 15:11:07 +0200 In-Reply-To: (=?utf-8?Q?=22Andr=C3=A1s?= Simonyi"'s message of "Fri, 16 Apr 2021 19:05:47 +0200") Message-ID: <87sg3neo0k.fsf@nicolasgoaziou.fr> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=217.70.183.199; envelope-from=mail@nicolasgoaziou.fr; helo=relay9-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_H2=-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: "emacs-orgmode@gnu.org" , 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=1618751527; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=9vtPjpuyhEBPsHGdJxccDlCftb30UdCD1kk4hron6U4=; b=jFZLXsJml+bKCHlxY0TSHFIBCGMdZZDzk7/N17h11PPxCCtrOaJVJyRUK+upM0zd4t2Zou Hz+HE3C2g2y4Zke/33zFUSSaCNExopupgfwdiL/lQdgU0t5kDp74t5+J1YOXAkSbOi9KK7 xp4jdSH7/JxH/FgwlGGj9LxKl0EfDlUHBgKvenqMusT4b4rit/xz2lQaJzsobjXbSn9H+P t0hGsQtdNi+aO4C6+1MtehdNrpa+aTcusY0sdfBpsPl+G+ASDnluK2/LVsDFANIO3cthX3 zwR575UQYE9YQV6AHR9MyLsqfDnppVOKyFbuR10bLvT0t3WX/8jaSXBPeO74rA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1618751527; a=rsa-sha256; cv=none; b=fHIA8XCDJ5lVgi4bz9D2Sba6+8R/LwvitjQaWb6bApWMi9aMVapn7+nvgd1llq3DiR1Tmp gVyCyY5jyA1eJmoxaJEGJW+OId+sR+IOMVupT8O6FmUaF/I9upAxfMEUGDMCsbO2AoE7m4 94KiiDChG3sEKcD5dnM/KW1XXdWuid6tb+XyDR2pBgjI7RDbftj0vHa0qY9nvIp4hK4Rh0 jaGqRI0XLbauQJ8WqavhwCZqbAgIwp8Ce2YRBdiUnVrh3FreQa09r36AGZgTCocnkcLQSd FlBE3I6EQqjRRmPN2iIU4jfCvo3yyZrs5OsT1rtfcI/V/8TevGwLK1QfX6owPQ== 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: -2.44 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: 479F4222C2 X-Spam-Score: -2.44 X-Migadu-Scanner: scn0.migadu.com X-TUID: JVaKzoa+L+EL Hello, Andr=C3=A1s Simonyi writes: > are short-form citations like @doe2018 or [@doe2018] also supported? No, I removed them in last year's iteration, because they are prone to false positives. I didn't want to repeat the footnote syntax mistake, when "[1]" was equivalent to "[fn:1]". I am also leaning towards removing the possibility to include Org syntax (e.g., bold) in prefixes/suffixes. Indeed, this doesn't sound terribly useful (you can move the bold part outside of the citation object), and yet, adds a layer of complexity on top of the citation object. Can we assume (global)prefix/suffix are just plain text? >> Now about the API, which is partly implemented on a local branch. > >> - "opening" action is straightforward. All is needed for the processor >> is to provide a function accepting two arguments: the citation key, >> as a string, and possibly a universal argument, which it may ignore, >> or not. >> >> All this is already implemented locally. > > I can imagine situations in which the location (e.g. page range) of > the citation is also important, e.g., when the > processor opens the cited document, so it'd be nice to pass this > information (when available) as well. In my mind, "opening" leads to the bibliography reference, not to the original document. IIUC, in this situation, the location does not matter much, does it? In any case, Org has no clue about the "location" of the citation. It can provide the suffix associated to the citation key, but it is up to the citation processor to extract page information out of it. If this is desirable, we need to provide the full citation object instead of the key. I don't know if it is worth the trouble. >> First, export happens as pre-process, before export back-ends are >> introduced. IOW, export back-ends are never going to see a citation >> object, which means no support whatsoever is needed on their end. > > This is pretty close to how citeproc-org operates right now. I had a quick glance at citeproc-org for inspiration. I agree this is a sane way to proceed. >> Support export requires two functions. The first function is >> responsible for rendering a bibliography. Its arguments are the list >> of citations in the document, the list of bibliography files, the >> style, if any, and the export back-end. It should return a string. > > Am I correct in assuming that the returned bibliography should be > rendered as a legitimate Org fragment regardless of the back-end? I think it should be rendered as target format, to be on par with citation handling. You may, however, use Org format as an intermediate step, and then, call `org-export-data-with-backend' (from "ox.el") on it. If this is desirable, I need to also provide a fifth `info' argument to the list above. >> The second mandatory function is obviously responsible for rendering >> citations. It is called with a citation object, the desired style, >> if any, and the export back-end, the full list of citations objets >> in the document, and the list of bibliography files. It should also >> return a string. Org provides a helper function to determine the >> footnote containing a citation (and its label, or number) from >> a citation object. > > This might not be an important point, but citeproc-el is rather > citation list oriented in the sense that it processes the list of all > citations and returns a list of their formatted counterparts, so it > might be useful to provide this "bulk" API as well, at least as an > optional addition. I don't think any addition to the suggested API is required. If you cannot split citation processing, you may fill a temporary cache holding all exports on first citation (the full list of citations objects is provided right from the start), then read from that cache on subsequent citations. WDYT? > What is very important and was rather tricky to implement as I recall > is that the list of citations should be in the order they actually > appear in the exported document even for citations in footnotes, > because certain styles format citations differently if another > reference to the same work occurred in a nearby, earlier note. Noted. IIRC, `org-export--footnote-reference-map' deals with a similar issue, i.e., how to apply a function on footnote references _in order_. Situation in nested footnotes can be ambiguous, tho. In the following example, is the expected order @a then @b then @c? --8<---------------cut here---------------start------------->8--- Text[fn:1] [@cite:@c] [fn:1] This[fn:2] is [cite:@b]. [fn:2] [cite:@a] --8<---------------cut here---------------end--------------->8--- > In addition to the precise order of the citations and whether they are > in a footnote or not, the concrete identity of the notes is also > important, because formatting can differ depending on whether two > citations are in the same note or in different ones. I don't understand what you call the "identity of the notes". Could you provide an example? >> - "fontification" is meant to give full access to face selection, what >> is really displayed, additional keymaps, all using a single >> function. > >> At the moment, I have no idea about what arguments would be useful. >> I think John Kitchin gave ideas about this already on this ML. >> I have to re-read his posts on the subject. In any case, feedback >> welcome. > > I'm thinking about implementing a "fontification" solution which would > use citeproc-el with a standard style to produce nice preview-like > representations of the citations in the buffer. This would require > basically the same pieces of information as citation export I think, > although it might be made strictly local, working only with the > single citation object plus the bibliography information. OK. Citation object and list of bibliography files as arguments are a starting point. >> A citation processor does not need to provide integration in all these >> areas. Users may be able to mix and match processors. This is another >> (minor) point which is yet to be designed. How is a user supposed to >> select a processor for each integration area? It could be done through >> three variables, e.g., >> >> (setq org-cite-display-processor 'org-ref) >> (setq org-cite-export-processor 'citeproc) >> (setq org-cite-follow-processor 'default) >> >> I think it is unlikely for a user to locally select "display" and >> "follow" processors. However, we need a way to use a local export >> processor for a given document. I may need to introduce >> a #+citation_processor keyword during export. Any other idea? > > All of these solutions seem to be good starting points. As for > setting the "display" and "follow" processors locally, this leads to a > question which probably has to be addressed at a certain point: that > of bibliography formats. The Emacs world is currently rather BibTeX > centered, but biblatex is an important (and rather different) > alternative, and there is CSL as well which I expect to become more > and more relevant (it's citeproc-el's native format). Moreover, these > formats have some variants, e.g., for BibTeX there is also org-bibtex, > for CSL there is CSL-JSON and a CSL-YAML etc. If different "display" > and "follow" processors will be able to handle different formats then > the users might want to change those settings locally as well, based > on the bibliography format, but I'm not sure what kind of > infrastructure would be the best way of supporting this. (E.g., > registering format support information about the processors and > choosing on this basis?) I don't have an idea about it either. This is not a blocker, tho. We can revisit it later, once we have "something" working. Thanks for your feedback. Regards, --=20 Nicolas Goaziou