From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id 5msaHac0lV5LIAAA0tVLHw (envelope-from ) for ; Tue, 14 Apr 2020 03:57:27 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id iHsLHqo0lV6hZwAAbx9fmQ (envelope-from ) for ; Tue, 14 Apr 2020 03:57:30 +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 16189941C81 for ; Tue, 14 Apr 2020 03:57:28 +0000 (UTC) Received: from localhost ([::1]:52180 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jOChS-0007GB-Nf for larch@yhetil.org; Mon, 13 Apr 2020 23:57:26 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:52811) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jNvvj-0005l5-A9 for emacs-orgmode@gnu.org; Mon, 13 Apr 2020 06:03:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jNvvh-0000yU-RA for emacs-orgmode@gnu.org; Mon, 13 Apr 2020 06:03:03 -0400 Received: from mout-p-103.mailbox.org ([80.241.56.161]:22316) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1jNvvh-0000rm-83 for emacs-orgmode@gnu.org; Mon, 13 Apr 2020 06:03:01 -0400 Received: from smtp1.mailbox.org (smtp1.mailbox.org [IPv6:2001:67c:2050:105:465:1:1:0]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mout-p-103.mailbox.org (Postfix) with ESMTPS id 49141Q1l67zKmVH; Mon, 13 Apr 2020 12:02:50 +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=1586772164; bh=mAwC6 m4hLYPybC8reu0QvqX5c6djnJWe7Ly8kC1Yz2k=; b=PTHcSBEFPsr9Iy+mOW29I 4maonFr4I814dbJFTqPRnibDE4z8o4UfDKloYPrmUq9p0EFzJaNFrv4pthFlYqO5 Zw480JFtj+zB9XcL8ds+EPamPEIqnHlsBteCTeml0y+HDR58UIRzkOv6i1ErCRXf uU+nzyq6uN1pjbLQiPJ6y7eqQ3tORZzqY5CYVcA2ZW+6dd4tvyJaIEhMpRCym+7D sRBBUOHyorHPBd6HjjrqAgt0SOKgCAtZM4YKeWA/P4Ikq374o8TcMiXCu+GZ5/f5 YJ/BPrWg/0mgRcTV5sJIsVas38elpj5KIpnTOcreIL5quP/Ls6D4wbHaLI1LI5jL g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailbox.org; s=mail20150812; t=1586772168; 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=C2zsAzfv35TYrAdTUlhQKyrU+jfRKEs34ElgLn3q5Cw=; b=h8Lr9OZQLKMWmY1fkYKn+oYaPtO8bXG09BEf1oplCQ7fF8v4YOTmzkb+pua7a52UdbcSlA umHgFHR8ek11+nGYRLOk6nlRhSY99l2HGaoafGjErjyiv4m1sX4MhQaGBTbynWDLIraoba Q+wvUxokmyAXPu2Z/ObMXIEUa7HPaTu/FdNEpuH4Q29Fev7ExvSGXr3Hhy6crMhxSHSSNg JkxXuNzOH/bg3t5chPU8ktmt9RYks3Hryz1FrfyJHyME9AgLDWZuycw3hWHl7i8SBTXi+H 9utmlV5QQ/wqR9rJL3FgizJ/1ieN403zHmdqEY/fPAgQHRDU4iIScZCwA8EN2A== X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp1.mailbox.org ([80.241.60.240]) by spamfilter02.heinlein-hosting.de (spamfilter02.heinlein-hosting.de [80.241.56.116]) (amavisd-new, port 10030) with ESMTP id nFQ--TlepRf5; Mon, 13 Apr 2020 12:02:44 +0200 (CEST) Date: Mon, 13 Apr 2020 12:02:43 +0200 (CEST) From: Denis Maier To: Stefan Nobis , emacs-orgmode@gnu.org Message-ID: <819880825.83337.1586772163860@office.mailbox.org> In-Reply-To: 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> 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: 3DB911778 X-Rspamd-Score: -4.40 / 15.00 / 15.00 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 80.241.56.161 X-Mailman-Approved-At: Mon, 13 Apr 2020 23:56:52 -0400 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 Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Scanner: scn0 X-Spam-Score: -1.71 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=mailbox.org header.s=mail20150812 header.b=PTHcSBEF; dkim=pass header.d=mailbox.org header.s=mail20150812 header.b=h8Lr9OZQ; dmarc=pass (policy=none) header.from=mailbox.org; 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 [-1.71 / 13.00]; HAS_REPLYTO(0.00)[denis.maier@mailbox.org]; GENERIC_REPUTATION(0.00)[-0.57642369939167]; 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]; RCPT_COUNT_TWO(0.00)[2]; HAS_X_PRIO_THREE(0.00)[3]; DKIM_TRACE(0.00)[mailbox.org:+]; 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@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)[]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; HAS_LIST_UNSUB(-0.01)[]; RCVD_COUNT_SEVEN(0.00)[7]; FORGED_SENDER_MAILLIST(0.00)[] X-TUID: FUARIlyY17Uq > 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