# longtable changes the page heading

Consider the following MWE:

\documentclass{article}
\usepackage{kantlipsum}

\usepackage{longtable}

\begin{document}
\section{First}
\kant[1]

% using this longtable changes the header from "1 First" to "2 Second":
% \begin{longtable}{ll}
%  bla & blub \\
%  bla & blub
% \end{longtable}

\section{Second}
\kant[2]

\end{document}


Curiously adding the longtable environment changes the page heading from »1 First« to »2 Second«. Am I missing something obvious? Does anybody know where to look for the cause?

-
Interesting question, but it has nothing to do with koma-script: The behaviour also arises for \documentclass{article}\pagestyle{headings}. I suggest you edit the question/MWE acordingly. –  lockstep May 6 '12 at 17:09
@lockstep Indeed, thanks! I thought I had tested this... –  cgnieder May 6 '12 at 17:12
duplicate (I think) of tex.stackexchange.com/questions/43406/… (or at least I knew I'd suggested that fix before...) –  David Carlisle May 6 '12 at 17:17

I think it's a bug sorry, there are similar (but different) instances in the bugs database, a workaround is to modify a local copy of longtable around line 402 to lose the vboxing.

      \global\vsize\@colht
%      \vbox
{\unvbox\z@\box\ifvoid\LT@lastfoot\LT@foot\else\LT@lastfoot\fi}%


If you let me know if that (a) fixes your real case and/or (b) breaks everything else, that would be useful information....

-
This seems to work. I just tested it with a larger document that uses several longtables. I can't see any issues so far. (I am out of upvotes for the day.. I'll vote tomorrow.) –  cgnieder May 6 '12 at 17:21
there is a danger that after handing back to the main document output routine that it (if it finds it hard to find a good break point for the next page) breaks the table _before _ the last foot as there are potential break points between the table rows. that's why (a lifetime ago) I left the final section boxed. But it messes up marks set on the last page (or in this small example set before the table) –  David Carlisle May 6 '12 at 17:26
I see. I'll keep that in mind... –  cgnieder May 6 '12 at 18:03

Building on David Carlisle's suggestion, here's a solution that doesn't require you to make a local copy of the file longtable.sty. Instead, it utilizes the macro \patchcmd of the etoolbox package. Inserting the following code in the preamble should do the trick.

\usepackage{longtable,etoolbox}
% The following code should only be used with v. 4.11 [2004/02/01, (DPC)]
%    of the longtable package. It will probably -- actually, almost
%    certainly! -- not work with other versions of this package.
% There are four separate occurrences of \vbox in "\LT@output";
%    must patch (i.e., eliminate) only the one that follows "\@colht".
\makeatletter
\patchcmd{\LT@output}{\@colht \vbox}{\@colht}{}{}
\makeatother

-
I think patching is the thing to do when extending package functionality, but if you are fixing a bug, then it's probably safer (and a better test of any potential official fix) to modify the package (and modify the ProvidePackage line to note the package has been modified) apart from anything else, I am not sure this is the best fix, but whatever the fix is, it is likely to make that patch fail to apply so the document would stop working if longtable gets updated. –  David Carlisle May 6 '12 at 19:12
I absolutely agree with you. My reason for providing the code for the \patchcmd route was to help people -- I suspect there are probably more than just a handful of them -- who don't know how to "modify a local copy of longtable" (and comment out the instruction on l. 402). To be sure, all of the caveats you've expressed about the perils of the bug fix using your method apply equally well to "my" method. I'll add some comments to the code to alert users that this patch will fail if and when the longtable package gets updated. –  Mico May 6 '12 at 19:46