[Top][All Lists]

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

Re: [wip-cite-new] Initial implementation of `biblatex' citation process

From: Denis Maier
Subject: Re: [wip-cite-new] Initial implementation of `biblatex' citation processor
Date: Mon, 19 Jul 2021 10:20:05 -0000
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1

Am 20.05.2021 um 12:36 schrieb Bruce D'Arcus:
On Thu, May 20, 2021 at 4:18 AM Denis Maier <denismaier@mailbox.org> wrote:

Could be, but also [cite/text/bare] or cite/foot/bare or cite/super/bare
as they all are essentially just wrappers around the plain cite command
(textcite is a bit different, but parencite and footcite really have the
same definition as cite, the only difference being that they add some
kind of wrapper.)
So, starting from parencite and then removing the wrapper would my logic
instead ;-)
But maybe cite/plain or cite/basic or so?

First, are those two suggestions just synonyms for cite/bare?

Yes. Nicolas complained about cite/bare so I've thought cite/plain may be nicer. (See autocite=plain) But the biblatex manual uses itself the term "bare".

Or are you indeed suggesting completely changing the current logic of
these styles and substyles? E.g "bare' substyle becomes rather a
"plain" or "basic" style?

I'm not really sure we need bare substyles at all. At least in biblatex it's the basis for the other commands. But anyway: My first suggestion was cite/bare, and the reasoning behing that was:
cite: is equal to cite/default:
cite/default is equal to cite/auto
cite/auto is equal to cite/parens or cite/note
cite/bare could be understood as cite/auto/bare, which is cite/note/bare or cite/parens/bare

I just don't really like the notion of first adding a wrapper just to remove it afterwards.

If yes, I need to think on this more.

| parens    | noauthor-caps | Parencite*   |
| parens    | noauthor      | parencite*   |
| parens    | caps          | Parencite    |
| parens    |               | parencite    |
| plain     | noauthor-caps | Cite*        |
| plain     | noauthor      | cite*        |
| plain     | caps          | Cite         |
| plain     |               | cite         |

Second, I don't understand some of the above.

Why "noauthor", for example? Is that not handled currently with a "year" style?


First of all, what does capitalization of a number mean? There's no \Citeyear in biblatex, after all. But that aside, \citeauthor, \citetitle and \citeyear are lower level commands than \cite*{}. \cite* will work in author-date styles and in author-title styles. It will either print the date or the title. When using \citeyear directly you cannot easily switch to a different style. And: citeyear etc. don't use the internal trackers (ibid., idem., etc.).

At the beginning Doe argues this and that (2020, p. 20). He goes on to say blabla, see ibid., p. 23.

In order to get the ibid., you'll need a \cite* instead of just a \citeyear or so.

And how would all of this map to natbib and citeproc? >
The style+substyles really should work well across the output formats,
and gracefully fallback if certain variants, particularly in biblatex,
aren't available in other formats.

Is that the case with your suggested changes?

The problem is indeed portability between csl and biblatex (and natbib). I think it's unavoidable that users who use biblatex specific commands loose that to a certain degree. Fallback mappings should be added, of course, but they will only get you so far. We should probably indicate which commands work in all packages so users can make their decisions consciously.

Perhaps we should start thinking from the high level commands:

| CSL             | biblatex                            |
| default         | autocite (=parencite or footcite)   |
| in-text         | textcite                            |
| suppress author | autocite* (=parencite* or footcite* |

FWIW, footcite* does not exist in all styles, so it will just behave like the regular footcite.


PS - I hadn't yet integrated sub-styles in this table, but we probably
need a table that does that.


reply via email to

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