From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id KPRcGFXUjV6VAgAA0tVLHw (envelope-from ) for ; Wed, 08 Apr 2020 13:40:37 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id yDwKBVbUjV4gYgAA1q6Kng (envelope-from ) for ; Wed, 08 Apr 2020 13:40:38 +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 035EA943438 for ; Wed, 8 Apr 2020 13:40:36 +0000 (UTC) Received: from localhost ([::1]:36160 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jMAwU-0001IW-AO for larch@yhetil.org; Wed, 08 Apr 2020 09:40:34 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:44160) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jMAvm-0001IG-9p for emacs-orgmode@gnu.org; Wed, 08 Apr 2020 09:39:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jMAvk-0002XT-MB for emacs-orgmode@gnu.org; Wed, 08 Apr 2020 09:39:50 -0400 Received: from mail-wr1-x431.google.com ([2a00:1450:4864:20::431]:43350) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jMAvk-0002Wg-9P for emacs-orgmode@gnu.org; Wed, 08 Apr 2020 09:39:48 -0400 Received: by mail-wr1-x431.google.com with SMTP id i10so1565776wrv.10 for ; Wed, 08 Apr 2020 06:39:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=andrew-cmu-edu.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AP5REsEvs/xisuB/ChKpQHqxdYxKw1hb0ZzIAI4fI8w=; b=gSle7C1wsRRE3HvCZhmubOHRGJuR3+4WgTwL04Ok8EFwX9Br6dfMIcFiMyP55qSU2s 0FlpvEy5A4DQ6TUgJQKM+c1ao4QmrkXRalJBC+HdqIg3CCFgyckd3hmz84Yt/FTXCPsm R6BuFeQGymgdzXW4Lg/ey7KouMKcXdcFCJfaiMr5u/39mYOjSeivv4C5Xqx9GW1qEnTp Df7jx0F1xVuGaDlKNCkQBwohdyIapGg8zuAYi6JKN0kpU1FNa2byAmtsBaCJaX6WTIyG iSfxPewMDej8kikYcDLyvggg03+iW1DQ65hhC56GeJhCiBbDzZZPHANWktGPp6cTD8K1 pkEw== 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; bh=AP5REsEvs/xisuB/ChKpQHqxdYxKw1hb0ZzIAI4fI8w=; b=UL/vT/0h/D+wkHwy8Y7DOVfKGGy16uNlE6fYzUch1dZ4gO9kqDVjOf6kUxhgcr5fzz c/ZQ4DqlQIHNuHqvs40S86eS2bIvijMnB3ej4RU2Hj+j+xl+iLG9FNvr9iyvrMpeUA8q ty72gB74HCgneZggXM2BIRaTBFO9JavZYer8slqKdp8m/epRo2YUrHFtHQ1rVPhMGL5f rebKydsuw2LULiQK5f6FLhLfjPNMzSLb0A9IaQtMES+K9rleOFQEqexeVPYIyj62HgA9 TiOwQyog2mqcD/jjSz/jH0+48W88jscI8SwsvcoNkgKxKYyOTSD9cW7p4THadvPP89yl E5Vw== X-Gm-Message-State: AGi0PuZiZaKeDEQcZdpu18h4hC/TSsijC1idxceHB6F/KIw66Y2Ve7MT 5S7gCedfFQsKH2q4i4r74C3juCrV4H5K1acHiXU= X-Google-Smtp-Source: APiQypLMSRP26RUvaqbNwCcc977GNqSCluGAoumEN6XZ1ly3ogAQjt1nHOS44OTBP+qNc5NKIHX8oqN9c7ebrDGbl9E= X-Received: by 2002:a5d:610b:: with SMTP id v11mr8296779wrt.212.1586353186336; Wed, 08 Apr 2020 06:39:46 -0700 (PDT) MIME-Version: 1.0 References: <87o8s389r0.fsf@nicolasgoaziou.fr> <874ktu8gr9.fsf@nicolasgoaziou.fr> In-Reply-To: From: John Kitchin Date: Wed, 8 Apr 2020 09:39:34 -0400 Message-ID: Subject: Re: wip-cite status question and feedback To: "Bruce D'Arcus" Content-Type: multipart/alternative; boundary="00000000000028f33505a2c7a2e5" X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::431 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: Joost Kremers , org-mode-email , =?UTF-8?Q?Andr=C3=A1s_Simonyi?= Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=default; t=1586353236; 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:dkim-signature; bh=AP5REsEvs/xisuB/ChKpQHqxdYxKw1hb0ZzIAI4fI8w=; b=jZM+QDPWs1h3qpYaqyfEs/ekTWqbKmRvzqUNIvioS5A2lbgURiXLdoO+L6rjMdfAZxxlkz YrOgM8AOJ/ky5bqHhg0Awf5g+oFG05Ve7/k9zjxuhtLpYUt05IXW7hTNVPZIbCqYBAQ1U3 3nXTjKnf2GyqqbHnWedc+n6I6INHRYg= ARC-Seal: i=1; s=default; d=yhetil.org; t=1586353236; a=rsa-sha256; cv=none; b=Ik/MA+Wust8CsvExeWOJppWqj47N9HKzFVPIjS5FLoSTJkqYwWNXfoAuNDGY7EUcrA00mZ Q8PUwvTYfm88UFGGO0TzpSpBMDNfdFYW4T2u/yZswUUW8QiRY1ayh7f3S+JUqaJ5N6PjSj ZDR3NsxXY2fJ0cwz1FpqYZIk5VJ5sPM= ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail (rsa verify failed) header.d=andrew-cmu-edu.20150623.gappssmtp.com header.s=20150623 header.b=gSle7C1w; 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-Scanner: scn0 X-Spam-Score: 2.59 Authentication-Results: aspmx1.migadu.com; dkim=fail (rsa verify failed) header.d=andrew-cmu-edu.20150623.gappssmtp.com header.s=20150623 header.b=gSle7C1w; dmarc=fail reason="SPF not aligned (relaxed)" header.from=andrew.cmu.edu (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-Scan-Result: default: False [2.59 / 13.00]; GENERIC_REPUTATION(0.00)[-0.58181825768969]; R_SPF_ALLOW(-0.20)[+ip4:209.51.188.0/24]; IP_REPUTATION_HAM(0.00)[asn: 22989(0.31), country: US(-0.01), ip: 209.51.188.17(-0.58)]; R_DKIM_REJECT(1.00)[andrew-cmu-edu.20150623.gappssmtp.com:s=20150623]; ARC_SIGNED(0.00)[i=1]; URI_COUNT_ODD(1.00)[3]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.50)[cached: eggs.gnu.org]; DKIM_TRACE(0.00)[andrew-cmu-edu.20150623.gappssmtp.com:-]; MAILLIST(-0.20)[mailman]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_RECIPIENTS_MAILLIST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:22989, ipnet:209.51.188.0/24, country:US]; TAGGED_FROM(0.00)[larch=yhetil.org]; FROM_NEQ_ENVFROM(0.00)[jkitchin@andrew.cmu.edu,emacs-orgmode-bounces@gnu.org]; ARC_NA(0.00)[]; RCVD_COUNT_FIVE(0.00)[6]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; SPF_REPUTATION_HAM(0.00)[-0.58429160151103]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[emacs-orgmode@gnu.org]; HAS_LIST_UNSUB(-0.01)[]; FREEMAIL_CC(0.00)[fastmail.fm,gnu.org,gmail.com]; FORGED_SENDER_MAILLIST(0.00)[]; SUSPICIOUS_RECIPS(1.50)[]; DMARC_POLICY_SOFTFAIL(0.10)[andrew.cmu.edu : SPF not aligned (relaxed),none] X-TUID: TSq+DuXN8gt5 --00000000000028f33505a2c7a2e5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable org-ref relies very heavily on the link functionality to provide actions on a cite, e.g. to open the pdf, or url, allow sorting, to change the cite color when it is a bad key, etc If the new syntax also has that capability, e.g. through font-lock, then I would consider integrating it into org-ref, but if not I think it would be a big regression in org-ref functionality. If I were to dream, each cite would have text-properties that include the key (so it is easy to get the key at point and do something with info in the corresponding database), and a help-echo function that could be user-defined, a face function that could be user-defined, a user-defined keymap, and some properties that define the bounds of the cite. While at it, maybe it is a good idea to allow a custom display, so one could toggle between a short cite (e.g. number or author year) and the full cites. These do not need to be part of the implementation, but if they were possible from the implementation it would be a lot more useful for something like org-ref. It would be a gain in quality of export, especially for non-LaTeX documents though, if there was an integrated citeproc. For the bibliography you need to support a few variants, IMO. One is bibtex-like, where you specify the source of the bibliography(ies) in the place where you want it to appear. The other is biblatex like, where the bibliography(ies) can be specified in a header or as properties, and you have another way to specify where in the document you want the bibliography to be. It should also be possible to have no bibliography, but the correct citations. And it should be possible to have the bibliography go to another file. Finally, the most common thing I do is use a default bibliography that is defined in a variable in my init file. This lets me put citations in org-files conveniently, but I almost never export these as they are usually just notes. If that all seemed possible, most likely it would make sense to start a new generation of org-ref that largely eliminated the links. I would probably still have to keep label and the ref links. There is not currently a way to reference equations otherwise. Tables and Figures seem ok with native org links. A new org-ref wouldn't happen fast, I guess it would be a year long project. But a clean slate would have some advantages to clean up and consolidate some things. John ----------------------------------- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu On Wed, Apr 8, 2020 at 8:19 AM Bruce D'Arcus wrote: > On Wed, Apr 8, 2020 at 5:32 AM Nicolas Goaziou > wrote: > > > > Hello, > > > > "Bruce D'Arcus" writes: > > > > > Note that in CSL processors, the locators are meaningful key-values, > > > basically; not plain text strings. > > > > OK, but it is enough for Org to feed a CSL processor with, e.g., > > > > key -> "@doe99" > > prefix -> "see " > > suffix -> ", pp. 33-35" > > > > Then CSL processor does its job to extract whatever information it > > needs. Am I right? > > On this, I would defer to Andr=C3=A1s and Albert (who maintains the pando= c > org code, I believe). > > Bruce > > > > Bruce > --00000000000028f33505a2c7a2e5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
org-ref relies very heavily on the link functionality= to provide actions on a cite, e.g. to open the pdf, or url, allow sorting,= to change the cite color when it is a bad key, etc If the new syntax also = has that capability, e.g. through font-lock, then I would consider integrat= ing it into org-ref, but if not I think it would be a big regression in org= -ref functionality.

If I were to dream, each c= ite would have text-properties that include the key (so it is easy to get t= he key at point and do something with info in the corresponding database), = and a help-echo function that could be user-defined, a face function that c= ould be user-defined, a user-defined keymap, and some properties that defin= e the bounds of the cite. While at it, maybe it is a good idea to allow a c= ustom display, so one could toggle between a short cite (e.g. number or aut= hor year) and the full cites. These do not need to be part of the implement= ation, but if they were possible from the implementation it would be a lot = more useful for something like org-ref.

It would b= e a gain in quality of export, especially for non-LaTeX documents though, i= f there was an integrated citeproc.

For the biblio= graphy you need to support a few variants, IMO. One is bibtex-like, where y= ou specify the source of the bibliography(ies) in the place where you want = it to appear. The other is biblatex like, where the bibliography(ies) can b= e specified in a header or as properties, and you have another way to speci= fy where in the document you want the bibliography to be.

It should also be possible to have no bibliography, but the correct= citations. And it should be possible to have the bibliography go to anothe= r file.

Finally, the most common thing I do is use= a default bibliography that is defined in a variable in my init file. This= lets me put citations in org-files conveniently, but I almost never export= these as they are usually just notes.

If that all= seemed possible, most likely it would make sense to start a new generation= of org-ref that largely eliminated the links. I would probably still have = to keep label and the ref links. There is not currently a way to reference = equations otherwise. Tables and Figures seem ok with native org links.

A new org-ref wouldn't happen fast, I guess it wou= ld be a year long project. But a clean slate would have some advantages to = clean up and consolidate some things.

<= div dir=3D"ltr">
John

-------------------------= ----------
Professor John Kitchin=C2=A0
Doherty Hall A207F
Departm= ent of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA= 15213
412-268-7803


On Wed, Apr 8, = 2020 at 8:19 AM Bruce D'Arcus <= bdarcus@gmail.com> wrote:
On Wed, Apr 8, 2020 at 5:32 AM Nicolas Goaziou <mail@nicolasgoaziou.fr= > wrote:
>
> Hello,
>
> "Bruce D'Arcus" <bdarcus@gmail.com> writes:
>
> > Note that in CSL processors, the locators are meaningful key-valu= es,
> > basically; not plain text strings.
>
> OK, but it is enough for Org to feed a CSL processor with, e.g.,
>
>=C2=A0 =C2=A0key=C2=A0 =C2=A0 -> "@doe99"
>=C2=A0 =C2=A0prefix -> "see "
>=C2=A0 =C2=A0suffix -> ", pp. 33-35"
>
> Then CSL processor does its job to extract whatever information it
> needs. Am I right?

On this, I would defer to Andr=C3=A1s and Albert (who maintains the pandoc<= br> org code, I believe).

Bruce



Bruce
--00000000000028f33505a2c7a2e5--