2

I am trying to compile a bibliography that will not accept someone's name that has an ogonek in it. I am not using \k, which I need for something else, so I did \let\ogonek\k and \newcommand{\eogonek}{\ogonek{e}} because at one point BibTeX had a problem with anything beginning with \o. The .bbl file that is produced begins with

\begin{thebibliography}{{St{\}}02}

which begins the person's name (the nonsense {\} is where the e-ogonek should be), and then the bibliography won't compile because it's missing a }. I understand this is supposed to be a width parameter at the beginning, and I can replace it with another name, as well as the \bibitem which is similarly broken, but I would just like to be able to compile normally without editing the .bbl manually every time. I do have \usepackage[T1]{fontenc} amongst various other things. This once worked on another system. I am using MacTeX at present.


EDIT: I have finally put together an MWE. Here is the .tex file:

\documentclass{article}
\usepackage[T1]{fontenc}
\let\ogonek\k       
\newcommand{\eogonek}{\ogonek{e}}
\renewcommand   {\k}            {k}
\bibliographystyle{alphaurl} 
\begin{document}
St{\ogonek{e}}pie{\'n}~\cite{stepien2002formal} showed...
\bibliography{bibshort}
\end{document}

Here is the relevant portion of the .bib file:

@article{stepien2002formal,
    author = "{St{\eogonek}pie{\'n}}, Zofia",
    journal = "Geom. Dedicata",
    number = "1",
    pages = "37--45",
    publisher = "Springer",
    title = "{On formality of a class of compact homogeneous spaces}",
    volume = "93",
    year = "2002",
    doi = "10.1023/A:102031393"
}

I compile this with the path txs:///pdflatex | txs:///bibtex | txs:///pdflatex | txs:///pdflatex | txs:///view-pdf.

The resulting .bbl file is the following.

\begin{thebibliography}{{St{\}}02}

\bibitem[{St{\}}02]{stepien2002formal}
Zofia {St{\eogonek}pie{\'n}}.
\newblock {On formality of a class of compact homogeneous spaces}.
\newblock {\em Geom. Dedicata}, 93(1):37--45, 2002.
\newblock \href {http://dx.doi.org/10.1023/A:102031393}
  {\path{doi:10.1023/A:102031393}}.

\end{thebibliography}

The mismatch in numbers of braces cause these errors, as recorded in the .log:

(./bib_ogonek_min.bbl)
Runaway argument?
{{St{\}}02} \par \bibitem [{St{\}}02]{stepien2002formal} Zofia {St{\eogonek \ET
C.
! File ended while scanning use of \thebibliography.
<inserted text> 
                \par 
l.9 \bibliography{bibshort}

I suspect you have forgotten a `}', causing me
to read past where you wanted me to stop.
I'll try to recover; but if the error is serious,
you'd better type `E' or `X' now and fix your file.


! LaTeX Error: \begin{thebibliography} on input line 1 ended by \end{document}.


See the LaTeX manual or LaTeX Companion for explanation.
Type  H <return>  for immediate help.
 ...                                              

l.10 \end{document}

Thank you for your patience.

jdc
  • 1,245
  • 5
    Using \k “for something else” is the issue. You can't use it for something else, because you do need it in the bibliography. Never ever redefine kernel commands with short names. – egreg Dec 04 '18 at 08:38
  • 2
    I can't reproduce the issue with the argument to \begin{thebibliography}, but I can easily provide an example of why naively redefining \k is a very bad idea. – egreg Dec 04 '18 at 08:50
  • @egreg: This is already an example, I assume? – jdc Dec 05 '18 at 02:19
  • No, it isn't. The offending bib entry and a short LaTeX document will be OK. – egreg Dec 05 '18 at 07:44
  • 2
    I agreed with the close vote because there is no usable example in this question and I could not reproduce the error when I tried to put the information in the question into MWE form. (See https://gist.github.com/moewew/c0ad5c2af369bdf157ac719b246cb091). I'll happily vote to re-open once a MWE is provided. Just ping me. – moewe Dec 30 '18 at 16:29
  • 1
    @moewe: I've added the MWE! – jdc Jan 04 '19 at 06:07
  • 2
    While we are at the subject of braces, I strongly dislike title = "{On formality of a class of compact homogeneous spaces}",. In this case there is no reason for the braces since there is nothing to be protected from case change (everything but the first letter is lower-case already) and in general it is much better to only protect the specific words that need to be protected from a case change rather than the entire title because that just disables the entire case changing function of BibTeX. See also https://tex.stackexchange.com/q/10772/35864. – moewe Jan 04 '19 at 17:07
  • In theory a style could apply the case change macro to all fields, but conventionally only title-like fields are affected. Hence only title fields need brace protection. I know of no style that would apply case change to name fields (and I believe that would be a very bad idea). So you should never have to protect names with braces (except corporate names https://tex.stackexchange.com/q/10808/35864). Braces change the 'brace level', which is important for stuff like https://tex.stackexchange.com/q/57743/35864. – moewe Jan 04 '19 at 17:10
  • 1
    The braces I'm talking about are not the outermost braces in <field> = {<value>}, as (in my eyes preferable) syntax for field = "<value>",. I'm talking about braces within the field value. – moewe Jan 04 '19 at 17:11
  • @moewe: I didn't see this comment earlier. The nested quotes and braces are probably the result of a careless copy-paste, as I don't normally do that either. A lot of my citations are copied from Google Scholar or were created by BibDesk back when I used it, and these typically have title = {...} and title = "..." respectively. Your last comment is meant to clarify that the outermost braces around your <value> are interpreted differently than the kind of braces which protect from case change and can be overused? – jdc Jan 05 '19 at 07:14
  • 1
    Yes, there are two ways to delimit field values: With quotes <field> = {<value>}, and <field> = "<value>",. The two forms are mostly interchangeable, but there are subtle differences between the two w.r.t. the behaviour when " appears in <value> (and I strongly prefer <field> = {<value>}, with braces, that's not the point of my comment, though). Whether or not you use braces there as value delimiter does not influence the brace level that does the case change. – moewe Jan 05 '19 at 07:19

1 Answers1

5

Redefining \k is a bad idea in any case.

If you like to live dangerously,

author = "{St{\eogonek}pie{\'n}}, Zofia",

should be

author = "St{\eogonek}pie{\'n}, Zofia",

Better yet, use

author = {St{\eogonek}pie{\'n}, Zofia},

Now you know why redefining \k is a bad idea. Indeed you get, in the document,

[Stke02]

instead of the expected [Stę02] as in the bibliography.

Is there any workaround? Yes, not redefining \k.

The issue is with hyperref, which expects all LICR commands (LaTeX internal character representation) to not be redefined, because its internals have to do several encoding switches. If you do

\show\ogonek

after \begin{document}, you will see

> \ogonek=macro:
->\PD1-cmd \k \PD1\k .

If you don't load hyperref, then your method may work.

egreg
  • 1,121,712
  • A very good example that demonstrates that it is always a good idea to avoid excessive bracing. – moewe Jan 04 '19 at 08:54
  • OK, this compiles, but the provided citation key is the counterintuitive [Stke]. How can I make this end with an e-ogonek or just an e?

    Is there any intution for what the braces do? I know that too few destroys the capitalization, but I didn't know there was such a thing as too many. In all my hours of playing with this entry trying to make it work, this approach never occurred to me.

    Why is redefining \k such a bad idea? Up until I came across this author, it was never an issue.

    – jdc Jan 04 '19 at 16:33
  • @jdc You could try \DeclareRobustCommand{\eogonek}{\ogonek{e}}, but really this is just trying to fix the symptoms rather than addressing the underlying cause. – moewe Jan 04 '19 at 16:50
  • 3
    @jdc I added more details. Braces around names are always wrong. Braces around parts of titles you want to keep the capitalization of are another thing. – egreg Jan 04 '19 at 16:50
  • 2
    @jdc There is pretty much only one reason to add braces to name fields: When you have a 'corporate author' (see https://tex.stackexchange.com/q/10808/35864). There are subtle differences in the handling of things that look like macros between different 'brace levels' in BibTeX. If you add unnecessary braces, the brace level may change and thus the result in the .bbl file. – moewe Jan 04 '19 at 16:56
  • 3
    @moewe Yes, you're right: braces around people's names are always wrong, but they are to be used for “corporate names”. – egreg Jan 04 '19 at 17:00
  • @moewe: Follow-up: if the author had been corporate, wouldn't this bracing be mandatory and yet produce the error? Or is this another example of how the right thing to do is just to not redefine \k? – jdc Jan 04 '19 at 21:47
  • 2
    @jdc Corporate author with accents and “alpha” style? That's a nightmare! By the way, “alpha” style is the worst I know. It was used at the time typewriters were the only way to produce manuscripts. Numeric or author-year is much better nowadays that citations can be generated automatically. – egreg Jan 04 '19 at 21:49
  • 1
    @jdc As far as I can tell this problem would indeed resurface if you had a corporate author (where the braces are necessary), not even {\k{e}} could help you there because of the brace level. But please don't let that be a reason to not to listen to the advice here: Don't use excessive bracing and don't redefine kernel commands like \k. – moewe Jan 04 '19 at 22:08
  • @moewe: It's not a reason not to listen! I was just curious. It's too bad there's no way to deal with that. I guess manually editing the .bbl would be in order in that case. – jdc Jan 05 '19 at 07:06
  • @egreg: Worst in what way? I like it as a compromise between including the author's whole name, which disrupts flow, and numerals, which give no information about the reference until the reader goes to the bibliography, and forces them to construct a mental index of what number means what article unless they want to keep flipping back every time the reference recurs. – jdc Jan 05 '19 at 07:09