From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id CN09LTA4lWC9WgEAgWs5BA (envelope-from ) for ; Fri, 07 May 2021 14:53:04 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id oBztKDA4lWCYGAAAB5/wlQ (envelope-from ) for ; Fri, 07 May 2021 12:53:04 +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 CAB4014715 for ; Fri, 7 May 2021 14:53:03 +0200 (CEST) Received: from localhost ([::1]:57804 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lezyY-0004ef-TX for larch@yhetil.org; Fri, 07 May 2021 08:53:02 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:57600) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lezcH-0001Pz-K4 for emacs-orgmode@gnu.org; Fri, 07 May 2021 08:30:01 -0400 Received: from mout01.posteo.de ([185.67.36.65]:43337) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lezcA-0001vW-Ng for emacs-orgmode@gnu.org; Fri, 07 May 2021 08:30:01 -0400 Received: from submission (posteo.de [89.146.220.130]) by mout01.posteo.de (Postfix) with ESMTPS id 1253E24002A for ; Fri, 7 May 2021 14:29:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1620390588; bh=n+4coCwKkjDEbAd6hcZTWxI6SYAJmn3Ys51/clAVCcE=; h=From:To:Cc:Subject:Date:From; b=CMnXvGh2a5IeHfeQhOk8djmEuI9SHLHcNMthMxm/lLd4BfM9qv4l4l+wBsfXUJcLy 8KYP0tz7ATFkSoRuv00l3b0wx6/QxTH9WGsnajGK512A86iWX56ug1tFaPq2CtV9qT 3G4wrVOFfItw3jc0/7mHtxJp4VdBZaL3y5fjUU+dV2xu6RjktpCvYy4BZOgHD+RjKE FQ4wIdOrw9tltaUscykCsp4wfRCcPHjFCvCsrRgwufzGpp+LMGA/9LfRG+AkzI1855 56o/WMHsZT8ndR3Fff34EDtfzGNNoV0YhjSlAaBpJKbStOAfl5Fo/wRhX+IDA+jADA OUtJbAr1kjzEQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Fc8sQ61r5z9rxS; Fri, 7 May 2021 14:29:46 +0200 (CEST) References: <87fsyy6at8.fsf@fastmail.fm> From: Titus von der Malsburg To: Joost Kremers Subject: Re: CSL-JSON support for =parsebib= In-reply-to: <87fsyy6at8.fsf@fastmail.fm> Date: Fri, 07 May 2021 12:29:46 +0000 Message-ID: <875yzuk9qd.fsf@posteo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=185.67.36.65; envelope-from=malsburg@posteo.de; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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, RCVD_IN_DNSWL_MED=-2.3, 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 List 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=1620391984; 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:dkim-signature; bh=CCYUbCwaOs62qVCGeTR1Gh9MPEWyBXpEZdFENvOlXSc=; b=mNriKyeR243yK0DsB1H+IyaKtmvgzrSChn/A0pKfhSmPWqHstt0Dajv5HshihTCjCLMxZ1 izRoKPOG8xxvFNvnDpvh19N8vxsjxTL7diANpb52hCCEIJeVppSI8CSV2lzgbB4nIX+1Iz 0HWvnknnIfJsJOI+ql/cptQzAAEl7uynwSxRiHHYcQqMP8Owfef4evpykYQt4DDFx31aZF P9n5NqzB8OaDeXUhTAphtcoe6wPmND+OCGgkyGqyrVFrIzFqPc7RNU19kfuoa3r0oCvMXD flvZewSZtt02Pb6M4QgAUl/6iNd3v+jYvEE6JO9UPiT3sCw8D+bLq3aDTWqi3w== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1620391984; a=rsa-sha256; cv=none; b=SXMTb43g4rERjKqfBB4txvcdPRG+p6D46uJPWE6xvRok0Qd0UNyh0B+OE0xJWWbhOlWDi/ py7bLgftX8s9XM8AzpdwTKNie9pJcsR1LZzWUY4cPWFjNxazgvDuImVneJvLWwBVgDTVur M5vekTUltXoz+T0VC0uuYqIVg23mtihMcQ1VeN1oDjlnm194pNsaJP78H5+lnZg+7Wibds 6Af8EUmTimhFIModEaCUfWVwpH6I4AkJlJyGyWescMRCDxeLq/nyEJ3o3ZsuzDSshigNFi e100nnnp5T4D/TRb/eT9PYiaEyC2ZEFv2yv8RH5yBB9jG9uWEZH9nCnzl96ZxQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.de header.s=2017 header.b=CMnXvGh2; dmarc=pass (policy=none) header.from=posteo.de; 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: 0.35 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.de header.s=2017 header.b=CMnXvGh2; dmarc=pass (policy=none) header.from=posteo.de; 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: CAB4014715 X-Spam-Score: 0.35 X-Migadu-Scanner: scn0.migadu.com X-TUID: DIyP4d79kFbD Hi all, I=E2=80=99m the maintainer of bibtex-completion, helm-bibtex, and ivy-bibte= x. My name is actually Titus, not Theo ;) Cool to see that the ecosystem around academic writing in org mode is devel= oping so nicely. I use org mode for this purpose every single working day = and it=E2=80=99s amazing already. I have to confess, though, that I haven= =E2=80=99t been keeping up with recent developments. I just saw the recent= thread about the citation syntax. (Thanks to Bruce D=E2=80=99Arcus for po= inting me to it.) Is there a good place where I can read up on the current= efforts and plans regarding citations, bibliographies and so on (I mean ot= her than reading the last couple of months of the mailing list archive)? Regarding the symbols vs. string issue: I don=E2=80=99t have a strong opin= ion, but personally tend to favor a conservative solution that avoids braki= ng changes. First, it=E2=80=99s difficult to predict how switching to symb= ols is going to affect other software including custom code written by user= s. Second, JSON key names can contain spaces and other weird stuff. So st= rings are perhaps a more natural choice anyway. (It appears that you can a= ctually configure the JSON parser to use strings instead of symbols. See v= ariable `json-key-type`.) Third, as you say, it would also be nice to main= tain compatibility with bibtex.el. Finally, it=E2=80=99s not necessarily c= lear that avoiding the conversion to strings saves sufficiently many CPU cy= cles to justify the effort. (But this may be a non-issue anyway, if the JS= ON parser can return strings directly.) Having said that, I=E2=80=99d be happy to merge a PR that that implements t= he switch to symbols in bibtex-completion if that=E2=80=99s the consensus. = Touches a substantial number of lines, but should nonetheless be relativel= y straightforward. Regarding support for CSL-JSON: bibtex-completion is currently very BibTeX-= oriented and uses fairly low-level parsing functions from parsebib. We cou= ld add similar support for CSL-JSON but things would become messy. (It=E2= =80=99s already a bit ugly, I have to say, which is entirely my fault.) It= might be more elegant to have a higher-level API in parsebib. This API co= uld perhaps even abstract away from the underlying format (BibTeX, CSL-JSON= , or others in the future?). This would substantially simplify matters in = bibtex-completion, but would also enable many other cool uses of parsebib. Some rough ideas for such an API (just for illustration): - A function that returns all entries in a .bib or CSL-JSON file. - A function that returns an entry with a specific key (or multiple entries= ). - Functions for resolving strings and cross-references. So much for now. Titus On 2021-05-07 Fri 11:17, Joost Kremers wrote: > Hi, > > [Cc-ing Theo von der Malsburg] > > Now that Org is getting support for Citeproc, it could be useful to add s= upport > for the CSL-JSON format for bibliographic data to Emacs. Therefore, after= a > friendly request from Denis Maier, I have added support for this format t= o the > =3Dparsebib=3D library. > > Since =3Dparsebib=3D is used by =3Dbibtex-completions=3D, which in turn i= s used by > =3Dbibtex-actions=3D, =3Dhelm-bibtex=3D, =3Divy-bibtex=3D, =3Dorg-ref=3D = and =3Dorg-roam-bibtex=3D, > this is a first step in making bibliographic data in =3D.json=3D format d= irectly > available to Org users, without the need of any BibTeX conversion. > > [Boy, look at me doing the marketing speak! :D ] > > Anyway, this really is the first step. =3Dbibtex-completion=3D will need = to be > modified in order to make use of the new functionality, and the same may = be true > of the packages based on it. > > At this point, the new code isn't merged into =3Dmaster=3D yet. It is ava= ilable in > the =3Dwip/csl=3D branch of =3Dparsebib=3D's Github repo: > > https://github.com/joostkremers/parsebib/tree/wip/csl > > The README has most of the details. I appreciate any and all comments, > suggestions and tips. > > For those maintaining packages based on =3Dparsebib=3D, I have at least o= ne > question: currently, =3Dparsebib=3D returns a BibTeX entry in the form of= an alist > of =3D( . )=3D pairs, where both =3D=3D and =3D=3D are strings. > A CSL-JSON entry is returned as an alist, but the =3D=3D names are= symbols, > not strings. > > It would be extremely impractical to return the JSON data with strings as= field > names, because the JSON parsing libraries in Emacs return symbols, so con= verting > them would take time. Plus, those libraries also expect symbols when seri= alising > Elisp data to JSON. (Which I intend to make use of in Ebib later on.) > > It would be easier to modify the BibTeX output to return field names as s= ymbols. > I originally chose strings, because that's what =3Dbibtex.el=3D uses, mak= ing it a > little easier to integrate with it. > > So the question: would it be helpful to make this change to the BibTeX da= ta, so > that the data from both sources uses the same format? Or would it be bett= er to > keep it as it is, even if that means that BibTeX data and JSON data isn't > compatible? > > TIA > > Joost > > > --=20 > Joost Kremers > Life has its moments