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 ms11 with LMTPS id mNnWDBA7lF6SbQAA0tVLHw (envelope-from ) for ; Mon, 13 Apr 2020 10:12:32 +0000 Received: from aspmx2.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id 6O5jJBI7lF6FMQAAB5/wlQ (envelope-from ) for ; Mon, 13 Apr 2020 10:12:34 +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 aspmx2.migadu.com (Postfix) with ESMTPS id DA1D4682453 for ; Mon, 13 Apr 2020 10:12:31 +0000 (UTC) Received: from localhost ([::1]:42498 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jNw4t-0002ds-EZ for larch@yhetil.org; Mon, 13 Apr 2020 06:12:31 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:53536) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jNw3q-0002Fd-P8 for emacs-orgmode@gnu.org; Mon, 13 Apr 2020 06:11:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jNw3p-0005JO-BD for emacs-orgmode@gnu.org; Mon, 13 Apr 2020 06:11:26 -0400 Received: from mout-p-101.mailbox.org ([2001:67c:2050::465:101]:46676) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1jNw3p-0005Ip-1P for emacs-orgmode@gnu.org; Mon, 13 Apr 2020 06:11:25 -0400 Received: from smtp1.mailbox.org (smtp1.mailbox.org [80.241.60.240]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mout-p-101.mailbox.org (Postfix) with ESMTPS id 4914CH0gVGzKm5K; Mon, 13 Apr 2020 12:11:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mailbox.org; h= content-transfer-encoding:content-type:content-type:mime-version :subject:subject:references:in-reply-to:message-id:reply-to:from :from:date:date:received; s=mail20150812; t=1586772679; bh=uja9D 24YRvbMMycK6ZgZuc+Hd4S4RGgIiJs6/OBnWRo=; b=gPIi63iRE9PSP6Ihv3rPN lgCqxJZivNxXyfH3n8et9JX5pRb7EoguWls9erhrUJib/24Agvk4zY5PIqWuOMgk LZrN276oKB4XuM8wEF/+9K5wqLsILKyUnK2qPOL0UoXH2H5nMyJt6Wm5byVz64wG ZhMuZw6t0lZzxJtN1RbIdFPc6Gbhj2krhcwAWiBdlbfzZHi0ODGXnd0h9k5uvsVa g5cGh8rNruhbRuIiFVWcUT8b/xvDxN4sVCLdbU8XLvR7ppChLA/eplRTfzuAOj3N PfI0GO0IwNZAs+eRRkqNghAtni2ExZxzwvTJiWrtB9jbRx6SE4Kl/BOkSwLY5KAa A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailbox.org; s=mail20150812; t=1586772681; h=from:from:reply-to: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; bh=iydY+jtxAFktgmvDph8RiocJ+eUNA3CuD3YDtMXT220=; b=T+1tGLNtKfjcX6upP3iSgKEXizEchqim/GsKrs58hurKGB6u/7Swf+wXMTe6rI7CJ69khh M845yBkBGsc8vw4iccpY3IPeyeRkJoxwMjDJ9C3TXImNjyDAxctsP4z6+4Czk4Ri9tIl0k KG9WCk8p9FYbAmQvJSQ1sNCLfzbp1U+xoVm1YSfitorxubF5ML55LNlpH3yQtQBrxmVG7g u4ezYm6y/rJngIoLwrdYl+3yBB3qCakjl3tMVzpSUdcyKVHJU689U9kQwKINXvzoCCjYK+ KRKiHzvaF72mGL4Co3KM9/wTO1A/UhTwGVypG6XWFWq1WOmpskZjaesj+4XkVQ== X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp1.mailbox.org ([80.241.60.240]) by hefe.heinlein-support.de (hefe.heinlein-support.de [91.198.250.172]) (amavisd-new, port 10030) with ESMTP id lSuY-JECKt0N; Mon, 13 Apr 2020 12:11:19 +0200 (CEST) Date: Mon, 13 Apr 2020 12:11:17 +0200 (CEST) From: denis.maier.lists@mailbox.org To: Stefan Nobis , emacs-orgmode@gnu.org Message-ID: <742638871.83370.1586772677138@office.mailbox.org> In-Reply-To: <819880825.83337.1586772163860@office.mailbox.org> References: <777184861.71192.1586510991834@office.mailbox.org> <87imi72bn0.fsf@nicolasgoaziou.fr> <1016821769.78551.1586641375789@office.mailbox.org> <87h7xp0z1y.fsf@nicolasgoaziou.fr> <874kto245n.fsf@nicolasgoaziou.fr> <87sgh8zpmg.fsf@nicolasgoaziou.fr> <1084456979.81820.1586724551265@office.mailbox.org> <877dykz6ri.fsf@nicolasgoaziou.fr> <819880825.83337.1586772163860@office.mailbox.org> Subject: Re: wip-cite status question and feedback MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Rspamd-Queue-Id: 13C761770 X-Rspamd-Score: -5.45 / 15.00 / 15.00 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2001:67c:2050::465:101 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: , Reply-To: denis.maier.lists@mailbox.org Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Scanner: scn0 X-Spam-Score: -1.71 Authentication-Results: aspmx2.migadu.com; dkim=pass header.d=mailbox.org header.s=mail20150812 header.b=gPIi63iR; dkim=pass header.d=mailbox.org header.s=mail20150812 header.b=T+1tGLNt; dmarc=pass (policy=none) header.from=mailbox.org; spf=pass (aspmx2.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 [-1.71 / 13.00]; HAS_REPLYTO(0.00)[denis.maier.lists@mailbox.org]; GENERIC_REPUTATION(0.00)[-0.57735272182581]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.51.188.0/24:c]; IP_REPUTATION_HAM(0.00)[asn: 22989(0.28), country: US(-0.01), ip: 209.51.188.17(-0.58)]; MX_GOOD(-0.50)[cached: eggs.gnu.org]; DKIM_TRACE(0.00)[mailbox.org:+]; RCPT_COUNT_TWO(0.00)[2]; HAS_X_PRIO_THREE(0.00)[3]; MAILLIST(-0.20)[mailman]; DMARC_POLICY_ALLOW(-0.50)[mailbox.org,none]; FORGED_RECIPIENTS_MAILLIST(0.00)[]; MIME_TRACE(0.00)[0:+]; 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)[denis.maier.lists@mailbox.org,emacs-orgmode-bounces@gnu.org]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[mailbox.org:s=mail20150812]; REPLYTO_EQ_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; HAS_LIST_UNSUB(-0.01)[]; FROM_NO_DN(0.00)[]; RCVD_COUNT_SEVEN(0.00)[7]; FORGED_SENDER_MAILLIST(0.00)[] X-TUID: xx+HACeqL88n > > Stefan Nobis hat am 13. April 2020 10:33 geschrieben: > > > > > > Nicolas Goaziou writes: > > > > > Alphanumeric suffix provides 62 combinations, which should hopefully > > > be enough for any citation back-end out there (I'm looking at you > > > biblatex). It's not terribly readable, tho, as you point out. > > > > I second that. Some of the many BibLaTeX commands are due to > > compatibility with other (older) packages and to ease transitions. > > > > Another aspect: Maybe it would be a good idea to reserve some chars > > (e.g. the numeric ones) for user defined citation commands (a > > minimalistic reserved namespace). > > My main concern is not so much the sheer number of available commands. I am just not sure if something like [cite6: @doe] will increase readability. (Will you remember what that is supposed to mean?) Also: With biblatex you have \nocite and \notecite, which one will be [citen: @doe]? I guess here I'd use citen for the more common option (nocite), but there still could be the need for a notecite version. Perhaps [cite-note: @doe] or [cite/note: @doe]. Again, a set of simple commands cite, citet, and perhaps a few others might a good starting point, but I am not sure if that is enough in the long run. (I currently use mainly CSL so I don't have much need for them myself, but I think extensability might become an issue at some point.) Also, some might prefer to have more verbose commands. > > By the way, I think you should add a nocite version to your proposal. (citen, citeno or something similar.) > > Concerning the fallback idea (citep being equal to cite if citep is not defined by a backend.) That's really good, but perhaps there should be a way to customize the fallback rules? Like a certain citex should be treated as cite, while citey is equal to citet... > WDYT? > > > > [Placing bibliography with "#+bibliography: here"] > > > It is smart, but I'm not sure I like using the same keyword for two > > > different things. OTOH, I don't have a better idea. > > > > I personally also dislike one keyword for completely different > > purposes. Therefore I suggest to take the idea from BibLaTeX and use a > > keyword like "printbibliography" the mark the place where the > > bibliography should be output. > > Ok, fair enough. > So: > #+BIBLIOGRAPHY: file1.bib > #+BIBLIOGRAPHY: file2.bib > [Rest of file] > > #+PRINTBIBLIOGRAPHY > > Or perhaps: > > #+BIBLIOGRAPHYFILE: file1.bib > #+BIBLIOGRAPHYFILE: file2.bib > [Rest of file] > > #+BIBLIOGRAPHY > > But ultimately, each will be fine. I don't think that matters much... > > > This command may also have parameters like filtering options (maybe > > depending on the backend processor; I only know BibLaTeX so I can't > > say if it would be easy to abstract away differences between different > > engines). In the case of BiBLaTeX the printbibliography command > > optionally accepts multiple key-value parameters. Some examples for > > the keys are "heading" for the chapter/section heading, "type" to > > output/print only entries of a certain type (like "book"; or type > > "online" and with the additional key "nottype" separate non-online and > > online sources), "keyword" to filter entries with the associated > > keyword etc. > > Yes, biblatex is very powerful here, and much ahead of other solutions. Pandoc has some support for multiple bibliographies, but it's nowhere as advanced. So offering something here would be great, but the question is how this can be done in a output agnostic way. > > > [Style selection] > > > I think this part is out of Org's scope. Since values between > > > various citation back-ends are probably not compatible, e.g., some > > > may require a file, others a style name, normalization is not useful > > > here. They can use whatever keyword they fancy. > > > > Yes, I second that. But it may be worth thinking a second about using > > one Org document to generate output with different backends (e.g. PDF > > via LaTeX and BibLaTeX, HTML, and ASCII). It would be nice, to have > > some way to configure each citation engine form the same document. > > Either use different keywords like "#+CSL_STYLE" and > > "#+BIBLATEX_STYLE" or we use your original suggestion of a ":style" > > parameter to the "#+BIBLIOGRAPHY" keyword and provide some means to > > translate its value individually for each engine - e.g. an alist or > > some function provided by the user. And if no translation is provided, > > just give the value verbatim to the engine, thus if a user only > > targets a single backend, he does not need to provide any > > extra configuration. > > These are very good questions. Looking again at pandoc: There you have two options: > a) use pandoc-citeproc to produce the citations for each target format > b) use a native bibliographic tool (e.g. biblatex or natbib in latex output). > > Option b) is clearly more powerful as you can use > But option a) can be used if you need the same output in DOCX, HTML and PDF. (Say you have an article written for a journal, and the manuscript is uploaded to your institution's repository.) That should be possible with Org as well. > > Best, > Denis