# Why to differentiate between \cite and \cites?

Is there any particular reason why one has to use \cites for more than one bibtex-key instead of \cite?

Considering the following MWE:

\documentclass{article}
\usepackage{biblatex}
\let\cite\cites
\begin{document}
\cite[12]{westfahl:space}[e.g.][23]{angenendt}

\cites[12]{westfahl:space}[e.g.][23]{angenendt}
\printbibliography
\end{document}


With \let\cite\cites I have no problem adding another bibtex-key to the \cite-command so it doesn’t matter if I forget the s in \cites for multiple bibtex-keys.

If it save to do so, couldn’t it be a default behaviour of biblatex?

• With \cite (without your redefinition) you can use \cite{westfahl:space,angenendt}, which produces the same output. Apr 22, 2017 at 19:10
• @Skillmon you are absolutely right, but with \cite{westfahl:space,angenendt} I cannot specify the pages. (I will adjust my example) Apr 22, 2017 at 19:12
• Well, beside the advantage of using command names that reflect what they are meant to do, biblatex uses more than just \cite and \cites (which they are based on). Try comparing \autocite[12]{westfahl:space}[e.g.][23]{angenendt} and \autocites[12]{westfahl:space}[e.g.][23]{angenendt}, for example.
– jon
Apr 23, 2017 at 2:23

Of course this is a design decision and we can't ask the original maintainer of the package, since he is not active any more. As far as I can tell, the separation between the normal cite command and the multicite-command (with s) has been there from the start.

The behaviour of the \cite command in biblatex largely coincides with the behaviour of that command with other packages. The multicite versions, however, offer additional features that not many (any?) other packages provide.

The syntax of the multicite commands is fully backwards compatible with that of the standard cite commands. So \let\cite\cites will not introduce more problems than you would have if you used \cites exclusively and never allowed yourself to use \cite. (Remember to \let all commands to their multicite counterparts, you don't want inconsistencies.)

I would strongly advise against making multicite the norm, though. The behaviour of cite and multicite commands in biblatex is so well-known and established that it should not be changed. Finally, the multicite commands are much more sophisticated and complicated due to their argument structure that it is better to only use them when necessary and not as default.

The set-up needed for the multi cite command is obviously a bit more intricate than the standard commands. That is why we define the standard commands first and then the multicite commands on top with

\DeclareMultiCiteCommand{\cites}{\cite}{\multicitedelim}


I assume that one of the reasons why the separation was kept is to allow to define a simple cite command first and then to top it off with a complicated multicite structure. This allows a layered approach.

The most compelling reason for maintaining the separation between the two, however, is that the multicite command is much more intricate and fragile. The nature of the multicite command dictates that it does not know the number of arguments beforehand. So it will have to scan ahead for things that look like arguments. Even though this is quite robust, there are situations where a more stable command that knows its numbers of arguments is preferable.

For example

\cite[pre][post]{key} ["this"]


works, because the \cite already has read all its argument and so knows that ["this"] can't be its argument. But in

\cites[pre][post]{key} ["this"]


\cites does not know that ["this"] is not one of its arguments. You need to stick in a \relax or \ to tell it to stop scanning: \cites[pre][post]{key}\ ["this"].

• +1. One warning though. \cite[pre][post]{key} ["this"] will work, but \cites[pre][post]{key} ["this"] won't, and needs to be \cites[pre][post]{key}\relax["this"]. Probably a rare case, but conceivable, and if it catches you ... In general I deprecate redefinitions which make standard commands have non-standard meanings in order to save 1 letter in a few cases. Apr 23, 2017 at 11:19
• @PaulStanley That is exactly one of the situations described in the manual that I tried to warn about. I think I will edit that in. Apr 23, 2017 at 11:22