BibTeX, biblatex and biber ⇒ biblatex | Command Name Conflict

[jmcLC]

In my preamble I have a new command definition using the following syntax:

Code: Select all

\newcommand{\RN}{\bcR^{\bcN}}

This command lets me print R^N in the sort of boldface I like. I've used this command without any problems for a couple of years. But I recently started using biblatex, and it seems there is a command name conflict. More specifically, \RN is a command that biblatex uses in connection with its display for Roman Numerals. So when I try to compile, I get an error. What is the simplest way for me to resolve this problem? I realize that I could replace my \RN command syntax in the preamble, for instance I could change to:

Code: Select all

\newcommand{\ReN}{\bcR^{\bcN}}

But wouldn't this require me to change \RN to \ReN everywhere it appears in all my source code files? I could make the changes using my text editor, but I have a lot of files, so it would take a long time to fix things using this approach. Is there anything simpler I can do?

Also, this raises a more basic question: Suppose the user wants to define a new command, and wants to check ahead of time to make sure that the syntax for their new command is not already in use by any popular packages. Is there a utility that exists that will allow the user to type in their contemplated syntax, and will check all existing (popular) packages, and then come back with either the response "yes, you can use that syntax without fear of conflict", or, "No, you can't use that syntax without a potential conflict, and here is a list of packages that already use your contemplated command syntax."


Any help would be appreciated!
Thanks,
Jerry

[cgnieder]

There is no such tool that I know of... would it be my document I'd probably change all appearances of my command using my editors search and replace function.

You can of course overwrite biblatex's definition. I can't say how important \RN actual is for biblatex. Depends on the style, I guess. So you could write

Code: Select all

\renewcommand{\RN}{\bcR^{\bcN}}

after loading biblatex. You should then probably carefully look at your citations and bibliography if you notice any strange effects.

Regards

[cgnieder]

Pfff, you might have mentioned that you also asked this question on TeX.sx, too (this would not only have been nice but is also part of our board rules). I'd probably have said then, that egreg's advice almost always is a very profound one... as in this case the following suggestion:

Code: Select all

% code by @egreg on TeX.sx:
%\newcommand{\RN}{\bcR^{\bcN}} % doesn't work any more
\let\biblatexRN\RN
\protected\def\RN{\ifmmode\bcR^{\bcN}\else\expandafter\biblatexRN\fi}

Regards

[Aardbei]

I just came across the same problem. Notably, also with Biblatex. The \x command is apparently also used in that package, and I had it in use for defining a vector. I know that it is not customary to define commands with only one letter (i.e. \x); see here for example: http://www.math.uiuc.edu/~hildebr/tex/tips-macros.html

To stir up this discussion again, I don't understand the reasoning behind the design of all this:

1. It begs the question: why does Biblatex to this? Is it just badly programmed this way?
2. Why can packages not have their own scope in which they declare variables? That way all things are separate from any user defined variables, which is how it should be: the user interface should only consist of commands to set options for packages.
3. Is there a way to check for command conflicts? Note that even when a conflict occurs, I get zero warning of this, it just fails on something in Biblatex. (Took me a long time to realise this was a command clash.)

I'm worried by the way this works in Latex. Actually, I'm surprised I didn't come across these conflicts before. I hope someone can explain the above questions or otherwise share thoughts on this.

[cgnieder]

Hi Aardbei,

Welcome to the LaTeX community!

I just came across the same problem. Notably, also with Biblatex. The \x command is apparently also used in that package, and I had it in use for defining a vector. I know that it is not customary to define commands with only one letter (i.e. \x); see here for example: http://www.math.uiuc.edu/~hildebr/tex/tips-macros.html

biblatex does not define \x. The following tells you that it is undefined:

Code: Select all

\documentclass{article}
\usepackage{biblatex}
\begin{document}
\meaning\x
\end{document}

It begs the question: why does Biblatex to this? Is it just badly programmed this way?

I use biblalex a lot and never had any such problems with it and I also haven't heard of others so I'd say the problem is a rather small one (and in your case must be another one anyway). biblatex actually is very carefully programmed and is maintained by very capable people who know what they're doing.

Why can packages not have their own scope in which they declare variables? That way all things are separate from any user defined variables, which is how it should be: the user interface should only consist of commands to set options for packages.

That is just the way TeX-programming works: everyone and everybody can define and redefine whatever they like at any time. With more than 1500 packages available conflicts are bound to happen. Good package programmers do take care though, to use internal commands that are very unlikely to be used by others. biblatex for example precedes its internal commands with \blx@ and similar prefixes. There is no way, however, this can prevent anyone from overwriting them again...

Is there a way to check for command conflicts? Note that even when a conflict occurs, I get zero warning of this, it just fails on something in Biblatex. (Took me a long time to realise this was a command clash.)

I would recommend this way: make you custom definitions in the preamble after you've loaded all packages and use \newcommand for defining new macros. This will give an error if the command is already defined. If it doesn't and the command is still not working something else must be going on.

Regards

[Aardbei]

Hi Aardbei,

Welcome to the LaTeX community!
biblatex does not define \x. The following tells you that it is undefined:

Code: Select all

\documentclass{article}
\usepackage{biblatex}
\begin{document}
\meaning\x
\end{document}

Thank you for your reply!

It took me a while but now I know what was happening. Indeed it's undefined in Biblatex, but when using it with Biber as backend (instead of Bibtex) then somewhere in the code the command \x{some hexadecimal? code} is used in the .bbl file as a way to represent characters from the .bib file that somehow do not have a regular representation (in ASCII I guess) and have some different encoding (Unicode?). There was one reference my .bib file that had one such obscure character. Bibtex apparently just skips these characters. Biber on the other hand apparently tries to map it to ASCII, but fails in this particular case, and also gives an error:

"\x{fffd}" does not map to ascii at Biber/Output/bbl.pm line 509.

Somewhat sloppy, Biber does not remove these commands from the .bbl file when they fail, causing errors when left for Latex to interpret them further. Whether \x is defined or not this of course produces errors. For example when I define \newcommand*{\x}{\mathit{x}} I get the expected error on the line number where I put \printbibliography:

\mathit allowed only in math mode.

(Because the reference list is not in math mode.)
So that's why it's hard to detect what's going on. I guess Biber somehow interprets \x on the fly while writing the bibliography, but if the command fails because it does not contain ASCII, it just skips the command and leaves it for (pdf)latex to process further. It doesn't redefine it though: \meaning\x returns 'undefined' when called before and also after the bibliography.

I use biblalex a lot and never had any such problems with it and I also haven't heard of others so I'd say the problem is a rather small one (and in your case must be another one anyway). biblatex actually is very carefully programmed and is maintained by very capable people who know what they're doing.

Okay , that's reassuring! Sorry to discredit them

That is just the way TeX-programming works: everyone and everybody can define and redefine whatever they like at any time. With more than 1500 packages available conflicts are bound to happen. Good package programmers do take care though, to use internal commands that are very unlikely to be used by others. biblatex for example precedes its internal commands with \blx@ and similar prefixes. There is no way, however, this can prevent anyone from overwriting them again...

I would recommend this way: make you custom definitions in the preamble after you've loaded all packages and use \newcommand for defining new macros. This will give an error if the command is already defined. If it doesn't and the command is still not working something else must be going on.

Regards

Thanks for the explanations, it is perfectly clear now how this all is intended to be used. Aside from that, the Biber issue above still seems to me could be implemented a little better to avoid confusion like I had...

[cgnieder]

Out of curiosity: could you post a minimal working example that shows the issues with \x?

[Aardbei]

Here goes. In the sample below a .bib file is created which has a long dash (—) in the title. I am no expert on these coding issues. I guess the dash is Unicode? It apparently maps to "fffd" multiple times as seen in the .bbl file and by the warnings it gives.

I hope the character comes through using a web browser. The dash is located between the words "dash" and "in" in the title. Note I changed my previous post to clarify some things.

Code: Select all

\documentclass{article} 
\usepackage[backend=biber]{biblatex} 
\addbibresource{refs.bib} 
\newcommand*{\x}{\mathit{x}}

\usepackage{filecontents}
\begin{filecontents*}{refs.bib}
@BOOK
    {test,
     AUTHOR  = "Author, Some",
     TITLE   = "{Let's put an em dash—in the title}",
     PUBLISHER = "The Publisher",
     YEAR = 2013
    }
\end{filecontents*}

\begin{document}
\cite{test}
\printbibliography 
\end{document}

[cgnieder]

I have no idea what's going wrong here but it must be due to the way the dash is read in by TeX. However, the issue disappears if you add \usepackage[utf8]{inputenc} to the preamble which tells TeX to use Unicode encoding.

Regards

[Aardbei]

Forcing it to use Unicode works. The dash even shows up correctly in the pdf file. I think you actually solved the problem! (Even though we don't understand exactly what's going on. )