From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:bcc0::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id isWYOzrPeWCqEQAAgWs5BA (envelope-from ) for ; Fri, 16 Apr 2021 19:54:02 +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 IJrZNDrPeWD1TgAAbx9fmQ (envelope-from ) for ; Fri, 16 Apr 2021 17:54:02 +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 47E5A1DAED for ; Fri, 16 Apr 2021 19:54:02 +0200 (CEST) Received: from localhost ([::1]:60804 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lXSfJ-00049J-7o for larch@yhetil.org; Fri, 16 Apr 2021 13:54:01 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:53922) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lXRuu-0000Bl-Tt for emacs-orgmode@gnu.org; Fri, 16 Apr 2021 13:06:06 -0400 Received: from mail-il1-x129.google.com ([2607:f8b0:4864:20::129]:37528) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lXRur-0000WA-HP for emacs-orgmode@gnu.org; Fri, 16 Apr 2021 13:06:04 -0400 Received: by mail-il1-x129.google.com with SMTP id j12so9790601ils.4 for ; Fri, 16 Apr 2021 10:06:00 -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 :content-transfer-encoding; bh=U4KlxZB8eAiF35ZG409CJyRpJbCqV8DrXGsqhizArTQ=; b=L4+K7RYh6nViF7fiff3RYNe8ixn0I5kGAzcqQWFXl3SSHLMbsLBwo3h2Pgn/uOrjzz oZ1lhq8RYzh7nh5m8/ip/5Ec8nQpBxP4pJUOJm7du2oYhK8cbaDbArJnFJ5iri90FdEl S+DY8SQoqHOalpAd9JyS/6zzFmfRs2QQyUIzYyONBF1UAr1Z2AVM8BxhC5uru/F8G5rg rEBrA9Bne1yCWmw3gwtGQJnOMQD+2HF4PJtdOsNhvjKgn7MgxkGJsPsHjqtvaPY1uX2z Eg+6BqaK70sxs33ejRnWPmoVfGOtVcoowhvzeSYEcYXx0dVtrn70/5G9JejUIm+9tPZ5 zGDA== 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:content-transfer-encoding; bh=U4KlxZB8eAiF35ZG409CJyRpJbCqV8DrXGsqhizArTQ=; b=dLNgTjUjuoq7MCNhzpCtqITXOtjfBH893lAqfbaRB1MKkb5lwh8UpS1Fg9fMF0T5yW w58M5kCFe3s4kkVuJoqvSpYVdtFV/tR2dUG0opq67YlUr+lbj0EGGqRfjMs4MplSV/kY BZvHwnXXAd+moRwgYwN7Sx4A2qdmA1GaK/+Gz8wBlhYzUGI6T1K4eFpkelce6vXlVri+ k9+WeAzq4vzRSyaRz4KxEq9WzQaSe9K9Wp3O82b7TlnDpHxgwQptwFOzdQuIzdjJcWHH s8nInsixcARXqem6HfXa+oyLGBFbs09FP5xTK8KCF5BK2GONg9ztoTmXiqYKue2UMwDs AVSg== X-Gm-Message-State: AOAM531Zbi8Vc5C4bOtIoqosb1hdnvdadmrp+kM/kgHOeU2hKtYxi72C lW0Phlp6ztEHtSYuwmjwsVWNuBcNUeFxqF8F5HQ= X-Google-Smtp-Source: ABdhPJwCmbjgDScxXWjIsS0ls8i+/D5lxmeSVYjmz9vj+W6DKqQPs63ISpLVIkwdWS+W27174wrASxG47kweccmfoS0= X-Received: by 2002:a05:6e02:1282:: with SMTP id y2mr7804540ilq.308.1618592759527; Fri, 16 Apr 2021 10:05:59 -0700 (PDT) MIME-Version: 1.0 References: <874ktu8gr9.fsf@nicolasgoaziou.fr> <87mu5xpm4x.fsf@gnu.org> <87img81ad7.fsf@gnu.org> <20210324182751.GA8721@atlantis> <87czuzprmh.fsf@nicolasgoaziou.fr> In-Reply-To: <87czuzprmh.fsf@nicolasgoaziou.fr> From: =?UTF-8?Q?Andr=C3=A1s_Simonyi?= Date: Fri, 16 Apr 2021 19:05:47 +0200 Message-ID: Subject: Re: wip-cite status question and feedback To: "Bruce D'Arcus" , "emacs-orgmode@gnu.org" , =?UTF-8?Q?Andr=C3=A1s_Simonyi?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2607:f8b0:4864:20::129; envelope-from=andras.simonyi@gmail.com; helo=mail-il1-x129.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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_FROM=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=1618595642; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=U4KlxZB8eAiF35ZG409CJyRpJbCqV8DrXGsqhizArTQ=; b=Fmg8OVAd3eO96wE9uzTSFsrDp7ZLhZ7TccM8Ej2clAt4CiDPGlrosDbQxhvdU61GvOJImR XSg3CqswNcWXsQBVUptfFgVpwV5TcGBvzP2kwlwI6/XG542Ptow2r5dTv3O6FCnz+g3u9n vgjovv2zlC/d71ZUj2kiacVVRV1j+7GRAyY5Jud5qmbH/DFc9/XPMTkZLcN1S19SDH15XF X0wCy/etAVvPgGkMfTpk2dZDQwqKiLtXeaY31NvoIeahlSPJf7tsBWUqtHKTONj7Q/NvSW PsCumzS5Po/Xf0CUtjGJFtCQCOwpsAkHFNLTWSFHVyJJjuRYZ8O/JXAVpePHmg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1618595642; a=rsa-sha256; cv=none; b=PAgz+XMuu9dNTUK60XRZxtXL3tzl9+2fJiEJnYQKCy4fNXrifHTGl3xvI+4pezp4xtT9Wi 68ZpeOw10LH2tFUBI79uwSqZz6x+zJmU5i/J66jhR+FEN07+OwSUAJCEcJeiioxFtqWGsG 6DPzRtTQK9vznzYN4ILyIhBr2+XUKhgEefH4EckU7EzIj7nJlL6XzFpgj5lw9VUOJLg4uh lydVexH7oKLyDt5euCfCn0y/O15aa+yuXLOS9ZIlv2EEtteDwEYnDt9Xe4/FTSh/Owbh8D ZS6HLKpt2yQl3HpVmLZctr6wGTmY9sH3vzg2UPjStDHFi1gbXLgqvg8RgHRw3A== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=L4+K7RYh; 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: -3.14 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=L4+K7RYh; 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: 47E5A1DAED X-Spam-Score: -3.14 X-Migadu-Scanner: scn0.migadu.com X-TUID: 5dE77RKbBROw Dear All, apologies for being this late with my reaction -- here are some comments/questions on Nicolas's summary: On Mon, 12 Apr 2021 at 15:19, Nicolas Goaziou wrot= e: > suffix" are all optional. So, in its minimal form, it can be as simple > as: > > [cite:@Doe:1995a] are short-form citations like @doe2018 or [@doe2018] also supported? > 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. > 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. > 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? > 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. 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. 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. > - "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. Providing really precise previews is probably out of scope here,because some details depend on global information about other citations which can frequently change and would be difficult to keep up-to-date. > 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?) > The last step is implementing a default processor. The point is to > provide a self-contained, very basic processor handling all three areas > described above. > > I started implementing one. It relies on built-in bibtex.el library, so > it assumes bibliography is written as a BibTex file. At the moment it > properly "follows" citations. It also exports citations as (Name, date). > However, it doesn't export bibliographies yet. It does not fontify > either. > > As a conclusion, besides the syntax, the branch is not ready for > inclusion yet. There are a few design questions about the API to answer. > Once done, and as long as no one has high expectations about the default > processor, this last part should not be too hard to complete. > > > Regards, > -- > Nicolas Goaziou Thanks again for working on this and best regards, Andr=C3=A1s