[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: wip-cite status question and feedback

From: denis . maier . lists
Subject: Re: wip-cite status question and feedback
Date: Mon, 13 Apr 2020 12:11:17 +0200 (CEST)

> > Stefan Nobis <address@hidden> hat am 13. April 2020 10:33 geschrieben:
> > 
> >  
> > Nicolas Goaziou <address@hidden> 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... 
> > [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]
> Or perhaps:
> [Rest of file]
> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]