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 ms0.migadu.com with LMTPS id IOqLI9tBlWCIcAEAgWs5BA (envelope-from ) for ; Fri, 07 May 2021 15:34:19 +0200 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 uHEvH9tBlWAJNgAAB5/wlQ (envelope-from ) for ; Fri, 07 May 2021 13:34:19 +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 CE87D14BD0 for ; Fri, 7 May 2021 15:34:18 +0200 (CEST) Received: from localhost ([::1]:41438 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lf0cT-0000HO-LN for larch@yhetil.org; Fri, 07 May 2021 09:34:17 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:45564) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lf0bX-0008VU-Jv for emacs-orgmode@gnu.org; Fri, 07 May 2021 09:33:19 -0400 Received: from mout02.posteo.de ([185.67.36.66]:53155) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lf0bR-0005L4-Jj for emacs-orgmode@gnu.org; Fri, 07 May 2021 09:33:19 -0400 Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id 9449D240100 for ; Fri, 7 May 2021 15:33:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1620394390; bh=5UvsHZgqSFt0WOFPKf/maz5tLi+1oS0CMsjZvh/6ggk=; h=From:To:Cc:Subject:Date:From; b=E/vHVgFKv8hwGHA1zBvI9do3G+Oyz/qyF9I1Z8rOPSyrlunb3z1LZiIyb5Jxea48B Y38Pt/JXFpzjK8s2OAuAV70Etp44uu9VZE3yUGwsEOh+EhujmBujETWBpc1xssPUoS +wEs/1TlZo1NY9QfjH4bLxdJDmuCR17pxwaWaXb6b9Nl3HBHYLK3VBCwMM7LW+hKhx aaFP3Fz0dgtPxcwAtCOxkug4JEzwOh8DlWb58rhYIdReqLDii6XMgjkbyaGlpJVFuA jjcEj4pC7DN6AWCzZxUxgSz0JHX41dvCdQi9sdhaGvsDImM/98R6pICkCsnHsgNAgg J5lgArEHl5dxg== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4FcBGZ0907z9rxM; Fri, 7 May 2021 15:33:09 +0200 (CEST) References: <87fsyy6at8.fsf@fastmail.fm> <875yzuk9qd.fsf@posteo.de> <875yzuwv4z.fsf@fastmail.fm> From: Titus von der Malsburg To: Joost Kremers Subject: Re: CSL-JSON support for =parsebib= In-reply-to: <875yzuwv4z.fsf@fastmail.fm> Date: Fri, 07 May 2021 13:33:09 +0000 Message-ID: <87tuneis8a.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.66; envelope-from=malsburg@posteo.de; helo=mout02.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_H4=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=1620394459; 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=qImFY1I8HI97uvmTrD2hhzvy3JpguKNRhIuU78enTac=; b=rMiy+vTOpblF4ALzGN7Kn86tc8XBjj6v8vubGiA5NHs/HYjclrtLY5EV1cBuh6epWG7fCL Sne4HS9yXelO3sKyTw/MqOWv6Jb0TX7GEYngotKEYrTxFI1WWAdS8v9G/wbqwPuN9nQzhQ CzRf3qZwdp7W+LTEbemc7Z9FxKUUrIGRjFKLICJIS3dgpqd4qEGfgimYBRa3xPLSqo4tyX OQP6t/J+RYRrMKWYJ12RlN3pc/Flt1UUh31TrwlhGbZ9KS86BWDm2yg07dVvs1e8o8rPiV msuwjQRqUkQworVElSU0gF6aSo+pEUSPl6EMPNCSoczwDOWBLUGRWjVQDj8fCw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1620394459; a=rsa-sha256; cv=none; b=bBSuypPOObK9165kmDNJ80x3jJ5ik/CO6HI6StdF0QOqIMhkFQ3Ek804ZZikc1mwaGaa4k oTBLYSKFSUrSjHd5fRQlXPD/z4hNuApjRiPzIZ24PdtjzBjOsKuzPJYRpRIFVU1mpguxrN j7XKKWLPuQmHbGyHSlV1awSflcH1q72+jpJ3NYgpXuYTQkjwKN4xAw+ZGx5Rfi7+BTw2gA AEAgIKddPAqKwrBEtutRE99UU8AWtjoDS/mA6MgdjUklpu9Sj3IE9vgW2biKnfxhUxC7/4 McrtIGdXkThUdU1qMbXSwd/JsZ+l+/W8f8Sac5NacL2Jvmt+3W623LUP7wBFuA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.de header.s=2017 header.b="E/vHVgFK"; 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="E/vHVgFK"; 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: CE87D14BD0 X-Spam-Score: 0.35 X-Migadu-Scanner: scn0.migadu.com X-TUID: sGI7mEcQgb6r On 2021-05-07 Fri 14:34, Joost Kremers wrote: > Hi Titus, > > On Fri, May 07 2021, Titus von der Malsburg wrote: >> I=E2=80=99m the maintainer of bibtex-completion, helm-bibtex, and ivy-bi= btex. My name is >> actually Titus, not Theo ;) > > :$ (I do apologise!) > >> Regarding the symbols vs. string issue: I don=E2=80=99t have a strong op= inion, but >> personally tend to favor a conservative solution that avoids braking cha= nges. >> First, it=E2=80=99s difficult to predict how switching to symbols is goi= ng to affect >> other software including custom code written by users. Second, JSON key = names >> can contain spaces and other weird stuff. > > Apparently, =3Djson-parse-{buffer|string}=3D then gives you a symbol with= a space in it... I now see that symbol names =E2=80=9Ccan contain any characters whatever=E2= =80=9D [1]. But many characters need to be escaped (like spaces) which isn= =E2=80=99t pretty. >> So strings are perhaps a more natural >> choice anyway. (It appears that you can actually configure the JSON pars= er to >> use strings instead of symbols. See variable `json-key-type`.) > > This works for the Elisp library =3Djson.el=3D, but Emacs 27 can be compi= led with > native JSON support, which, however, doesn't provide this option, unfortu= nately. I see. In this case it might make sense to propose string keys as a featur= e for json.c. The key is a string anyway at some point during parsing, so = avoiding the conversion to symbol may actually be the best way to speed thi= ngs up. >> Finally, >> it=E2=80=99s not necessarily clear that avoiding the conversion to strin= gs saves >> sufficiently many CPU cycles to justify the effort. > > I can simply try it out. Shouldn't be difficult to code up. > >> Regarding support for CSL-JSON: bibtex-completion is currently very >> BibTeX-oriented and uses fairly low-level parsing functions from parsebi= b. We >> could add similar support for CSL-JSON > > I'm afraid that won't be possible, because the CLS-JSON support in parseb= ib > isn't low-level. ;-) There's basically just a single function that gives = you all > the entries in the buffer and that's it. > >> Some rough ideas for such an API (just for illustration): >> - A function that returns all entries in a .bib or CSL-JSON file. > > Those already exist... ;-) For JSON, that's basically the only option, be= cause > the actual parsing isn't handled by parsebib. For BibTeX, such a function= has > existed for some time now. Wasn=E2=80=99t aware. Fantastic! >> - A function that returns an entry with a specific key (or multiple entr= ies). > > That would be easy to support, but IMHO is better handled in bibtex-compl= etion: > just parse the buffer and then call =3Dgethash=3D on the resulting hash t= able. Or > what use-case do you have in mind? One use case: bibtex-completion drops fields that aren=E2=80=99t needed ear= ly on to save memory and CPU cycles. (Some people work with truly enormous= bibliographies, like crypto.bib with ~60K entries.) But this means that w= e sometimes have to read an individual entry again if we need more fields t= hat were dropped earlier. In this case I=E2=80=99d like to be able to read= just one entry without having to reparse the complete bibliography.=20 >> - Functions for resolving strings and cross-references. > > This, too, is something that parsebib already does. OMG, bibtex-completion is doing this as well, but I=E2=80=99d be happy to g= et rid of this code. > parsebib has a lower-level API and a higher-level API, and the latter does > essentially what you suggest here. I thought bibtex-completion was alread= y using it... Nope. I think the high-level API didn=E2=80=99t exist when I wrote my code = in 2014. Seems like there=E2=80=99s quite a bit of potential for streamlining bibtex= -completion. Now I just need a week to work on it. :) Titus [1] https://www.gnu.org/software/emacs/manual/html_node/elisp/Symbol-Type.h= tml