Math & Science ⇒ loading breqn package before biblatex gives warning

[cgnieder]

I wanted to post the following answer:

Yes, I know that sometimes packages need to be loaded in a certain order, e.g. all things to do with internal links (the packages you mention). But in this case, the biblatex package seems unrelated to the breqn package, so I thought it's strange that the warning pops up.

As you've posted in you first post it isn't biblatex directly but etoolbox (a package which provides useful programming tools and is used by various other packages besides biblatex, too).

The thing is that both breqn and etoolbox redefine the very fundamental LaTeX command \end and obviously breqn does it in a way incompatible to etoolbox.

Code: Select all

% breqn's redefinition:
\def\@tempa#1\endcsname#2\@nil{\def\latex@end##1{#2}}
\expandafter\@tempa\end{#1}\@nil
\def\end#1{\csname end#1\endcsname \latex@end{#1}}%

Code: Select all

% etoolbox's redefinition:
\newrobustcmd{\AtEndEnvironment}[1]{%
  \csgappto{@end@#1@hook}}

\patchcmd\end
  {\csname end#1\endcsname}
  {\csuse{@end@#1@hook}%
   \csname end#1\endcsname}
  {}
  {\etb@warning{%
     Patching '\string\end' failed!\MessageBreak
     '\string\AtEndEnvironment' will not work\@gobble}}

But when posting the code I realized there shouldn't be any conflict between breqn and etoolbox. And indeed: I cannot reproduce the error - the order of biblatex and breqn doesn't seem to matter with an up to date TeX Live 2013.

[Aardbei]

But I use (an updated) MikTeX 2.9
(Edit: I meant 2.9 sorry)

Also, the conflict (in relation to the warning message) isn't between etoolbox and breqn; but between biblatex and breqn. With etoolbox the warning actually disappears.

Can you reproduce the errors resulting from using minipage, which seem much more severe?

[cgnieder]

But I use (an updated) MikTeX 1.9.

The current version of MiKTeX is 2.9!

Also, the conflict (in relation to the warning message) isn't between etoolbox and breqn; but between biblatex and breqn.

This is best answered with your first post:

When I load the breqn package before the biblatex package it gives the following warning:

Package etoolbox Warning: Patching '\end' failed!
(etoolbox) '\AfterEndEnvironment' will not work.

This is no doubt an etoolbox warning and not a biblatex warning! And it is directly related to etoolbox's patching of \end which can be seen in the code I posted earlier.

But I've been sloppy when reading the log file, sorry for that! I can reproduce it:

Code: Select all

\documentclass{article}
\usepackage{breqn}
\usepackage{etoolbox}
\begin{document}
\end{document}

gives

Code: Select all

Package etoolbox Warning: Patching '\end' failed!
(etoolbox)                '\AfterEndEnvironment' will not work.

Quite interestingly though applying the patch again manually works:

Code: Select all

\documentclass{article}
\usepackage{breqn}

\usepackage{etoolbox}
\tracingpatches
\makeatletter
\patchcmd\end
  {\csname end#1\endcsname}
  {\csuse{@end@#1@hook}%
   \csname end#1\endcsname}
  {}
  {\etb@warning{%
     Patching '\string\end' failed!\MessageBreak
     '\string\AtEndEnvironment' will not work\@gobble}}
\makeatletter

\begin{document}
\end{document}

The log:

Code: Select all

Package etoolbox Warning: Patching '\end' failed!
(etoolbox)                '\AfterEndEnvironment' will not work.

) (/data/texlive/2013/texmf-dist/tex/latex/etoolbox/etoolbox.def)
[debug] tracing \patchcmd on input line 8
[debug] analyzing '\end'
[debug] ++ control sequence is defined
[debug] ++ control sequence is a macro
[debug] ++ macro can be retokenized cleanly
[debug] ++ search pattern found in replacement text
[debug] ++ patching possible
[debug] == retokenizing macro now

I'll try to investigate when I have a little time.

Can you reproduce the errors resulting from using minipage, which seem much more severe?

Yes, but this is another matter. I haven't a solution for it, yet.

Best

[Aardbei]

Okay, we'll see if the developers can get wind of these two things and resolve them. Thanks for investigating!

[daleif]

A bit slow to react here.

At the moment, no futher work is being done on breqn. Including debugging. The remaining maintainers basically do not have the time.