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 ms11 with LMTPS id iJEYNwuG0V5JJAAA0tVLHw (envelope-from ) for ; Fri, 29 May 2020 22:00:43 +0000 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 MCv+MguG0V7yYgAAB5/wlQ (envelope-from ) for ; Fri, 29 May 2020 22:00:43 +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 2B7499402D6 for ; Fri, 29 May 2020 22:00:43 +0000 (UTC) Received: from localhost ([::1]:38446 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jen3Q-0006lq-UO for larch@yhetil.org; Fri, 29 May 2020 18:00:40 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:56814) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jen2w-0006lU-K3 for emacs-orgmode@gnu.org; Fri, 29 May 2020 18:00:10 -0400 Received: from mail-io1-xd2a.google.com ([2607:f8b0:4864:20::d2a]:38144) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jen2v-0002r5-5t; Fri, 29 May 2020 18:00:10 -0400 Received: by mail-io1-xd2a.google.com with SMTP id d7so979738ioq.5; Fri, 29 May 2020 15:00:07 -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 :cc:content-transfer-encoding; bh=epgFqpw5NTd1rQ/03gKrBft4+V6qA3plO5/bAUbs7OY=; b=DTRaKAxJiCpPzYDa6UndxihAyL98HC4KYUyAJKe4KrpCxC50myg3jFnvugJoZoeaNv 0ovFAhwZjM8AUd5RS5pLd1OviMD73KP71EL2LuSRzfTmV0d8OA6T/DCHvBoPELdEo6WN j0Cd+CumTcsaW3JbmipLMjNqLX3PIhpLk7ppCzXoycEL3kZXqGI4g6euN64lrzSwBOZ5 /8JGJaBw1wxtu3JjqhvCaa5nVCYMSrzxlZzrHjUuroEunIxg/2qO4/1pwnbRX3f5/ZLy yg2/xnag5gz1Vy2TBpzuCMWur6sST6pOMHm23dmtsS4Auqfp6bz1nGE/Yxcmk7pDhih5 VmdA== 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:cc:content-transfer-encoding; bh=epgFqpw5NTd1rQ/03gKrBft4+V6qA3plO5/bAUbs7OY=; b=YOiNtqyv0Si42kQVsmR8uG0fqVn9mwzzgP0PIU0Q+LY2CGc1l7pAe54fA5H8pdV4vj vk3CeYQWEa+VBebUY4tbhlYVeb2M/BDwS3ELDaqySbRIl4thJdoh2zXALB3yd6GXLopn 47l38+ME95VhU0VvZv2auv5D1uedrkPwK91FUR08KXbTziS8Kh05ReQGA8P+lCLngToL nwBqz1pd2znOZbu2ADvEi8+AOQremt4VMHpvriJC2PBTidc0QHc5dBwAttlhHFqXrOuN sJzjRtS8z9tJINyDhS+Pct6ZwEBWbfrX8EvNOm6x8Qupf++GHjJymD625Em6DbCm2woX aDFg== X-Gm-Message-State: AOAM532Cy5mapMcEBP4rxZFD0SGBwdFyHa3qVoSVYioaipT51AlZwhtr sBf6ltZa8EiuAcl2rhjOs1BQyfP/2wdXqySXnQs= X-Google-Smtp-Source: ABdhPJz5M5njEreilHIMZqle55VSE0wuSgb+AeQ+QCo2Mmqzxzb6ax8a29oxM9T+UzZgzXJTc9bjaEJiB9MPvFeB3jc= X-Received: by 2002:a02:7f4d:: with SMTP id r74mr9067364jac.51.1590789606511; Fri, 29 May 2020 15:00:06 -0700 (PDT) MIME-Version: 1.0 References: <87o8s389r0.fsf@nicolasgoaziou.fr> <874ktu8gr9.fsf@nicolasgoaziou.fr> <87mu5xpm4x.fsf@gnu.org> In-Reply-To: From: =?UTF-8?Q?Andr=C3=A1s_Simonyi?= Date: Fri, 29 May 2020 23:59:54 +0200 Message-ID: Subject: Re: wip-cite status question and feedback To: "Bruce D'Arcus" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2607:f8b0:4864:20::d2a; envelope-from=andras.simonyi@gmail.com; helo=mail-io1-xd2a.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. 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, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN 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: John Kitchin , Joost Kremers , =?UTF-8?Q?Gustav_Wikstr=C3=B6m?= , Bastien , "emacs-orgmode@gnu.org" , Nicolas Goaziou Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=fail (rsa verify failed) header.d=gmail.com header.s=20161025 header.b=DTRaKAxJ; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=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-Spam-Score: 0.09 X-TUID: FGWzVI0bnwqB Hi, apologies for reacting that late (it seems that I messed up my email filter= ing royally) -- it is very nice to see progress in this area. Thanks to all of = you for trying to bring this forward, and, of course, to Bruce for initiating t= he thread. I think that the syntax that has crystallized is a good starting point for having dedicated citation support in Org, so in the following I'll concentrate on = some of the infrastructure issues raised. (i) Default ("built in") citation processor in Org I think citeproc-el could be a reasonable solution for this. The core is well-tested (thanks to the CSL test suite), implements a fairly large subse= t of the CSL 1.01 standard, and can output citations in a number of formats incl= uding in Org syntax. If I understood correctly, this would require citeproc-el to= be part of Emacs, and not even an ELPA package would suffice. In principle I'm= open to this, but I'm not familiar with the process and there are potential pitf= alls, e.g. citeproc-el currently depends on some "modern" libraries, e.g., "s" or "dash" which AFAIK are not in Emacs. (ii) Citation API NG =3D=3D Nicolas Goaziou wrote on 8 Apr 2020 NG> 2. [ ] Decide about API Org should provide for it to be useful. Here = are NG> some low hanging fruits: NG> - [ ] List all ".bib" files associated to the document, NG> - [ ] List all citations, NG> - [ ] Return citation key at point, if any. NG> - Anything else? >From the citeproc-el (and CSL) perspective, the list of bibliography databa= se files, the place where the bibliography should be placed (if it's specified= ) and the list of citations would be enough, I think. For the proper handling of footnote-based styles it would be important to provide footnote information about each citation: is a citation in a footnote and what is its footnote n= umber (index in the list of footnotes)? (citeproc-org contains a function to coll= ect this info.) NG> Moreover, we need to decide about how external processors could plug = into NG> the export framework. NG> - [ ] For example, it could be a simple variable bound to a list o= f NG> functions. Each function accepts three arguments: the export back-end= , as NG> a symbol, the full citation, as a list of triplets (key, prefix, suff= ix) NG> along with global prefix/suffix, and the usual INFO communication cha= nnel. NG> Does it need more? Unfortunately I'm unfamiliar with the Org exporter, so this might not be a problem at all, but there is a seemingly tricky point during export, relate= d, again, to footnotes in footnote-based citation styles: If a footnote style = is used and a citation is not already in a footnote then a footnote has to be dynamically generated around the citation during export. The simplest way o= f doing this is to wrap the rendered citation (which can contain backend-spec= ific font-properties, e.g. smallcaps) into an inline Org footnote block. E.g., citeproc-org, which basically acts as an Org->Org preprocessor, generates dynamical footnote citations for html export along the lines of [fn:: @@html:G=C3=B6del 1931= @@] If this scenario can be handled by the proposed mechanism then I don't expe= ct any other problems. NG> - [ ] Also, the prefix/suffix may contain some Org markup, so this NG> needs to be also processed. Should it happen before, or after the ext= ernal NG> processor does its job? I.e., should the function translate into Org = or NG> target format? This is a very good (and a bit tricky...) question! Since the proposed Org citation syntax does not contain locator-related slots, the citation proces= sor has to locate this information in the affixes (in citeproc-org, in the suff= ix), parse and remove it. This part should definitely be done in Org format, so = I'd say the Org markup rendering should be after the citation rendering. (With = the proviso that part of the citation processor's output can already be rendere= d in the target format as in the previous example.) NG> 3. [ ] Specify the kind of basic translation that be done out of the = box? NG> Ideally, every non-derived back-end should do something, even basic. NG> Therefore, we need to propose some translation pattern for each of th= e NG> following: NG> - [ ] ASCII NG> - [ ] HTML NG> - [ ] LaTeX NG> - [ ] ODT NG> - [ ] Texinfo As an Org->Org preprocessor, citeproc-org supports all these back-ends in t= he sense that for HTML and LaTeX it outputs target specific rendering using th= e @@latex and @@html syntax and generic Org for the rest. (iii) Citation visualization JK =3D=3D John Kitchin wrote on 8 Apr 2020 JK> org-ref relies very heavily on the link functionality to provide acti= ons JK> on a cite, e.g. to open the pdf, or url, allow sorting, to change the= cite JK> color when it is a bad key, etc If the new syntax also has that JK> capability I'd add to this that it would be very useful if citations -- similarly to l= inks -- had a "descriptive" (as opposed to "literal") rendering mode in the buff= er as well, which would show the rendered citation, as produced by a citation processor (if available). Similarly to links one could toggle between the t= wo display modes. (iv) Bibliography format This might go without saying but perhaps it's worth specifying which bibliography format(s) should be supported by the "out of the box" functionality. My impression is that despite the clear superiority of biblatex and CSL, Bi= bTeX is still the most widely used format, and should be the first/main target. = Later on, of course, it would be nice to support others, e.g., using a CSL proces= sor one basically gets CSL-JSON support for free, and there could be even an Or= g-CSL format, by analogy with Org-BibTex. What do you think? Sorry again for replying only now & best regards, Andr=C3=A1s On Sun, 24 May 2020 at 15:18, Bruce D'Arcus wrote: > > Hi Bastian, > > > On Sun, May 24, 2020 at 8:12 AM Bastien wrote: > > > > Hi Bruce, > > > > "Bruce D'Arcus" writes: > > > > > I'm not sure of the value of this sort of question thrown in the > > > middle of a long-running, many year, conversation. You seem to assume > > > nobody considered this. > > > > Well, this sounded a bit harsh, problably more than what was intended. > > Yes, probably true. > > I was trying to be direct, to avoid a potentially long-winded diversion. > > But it was a bit harsh. Sorry Gustav. > > > > But to answer anyway ... > > > > And your answer was precisely what I was (also) looking for, so thanks > > for it. I haven't followed nor helped developments in this area but I > > hope this can settle down and be widely available. > > Indeed; thanks! > > Bruce