Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

\@mkboth inside \chapter* in \tableofcontents #54

Closed
kberry opened this issue Jul 1, 2018 · 2 comments
Closed

\@mkboth inside \chapter* in \tableofcontents #54

kberry opened this issue Jul 1, 2018 · 2 comments

Comments

@kberry
Copy link

kberry commented Jul 1, 2018

Claudio Beccari (claudio.beccari at gmail.com) wrote me the following. 1) His reasoning seems plausible; 2) I am doubtful you will want to make any change; 3) I didn't feel it was my place to make the decision. I imagine Claudio could provide an example document showing the problem, if useful. Thanks ... --karl


From: Claudio Beccari

The book standard class had the \table of contents macro un modified for
the past, maybe, 30 years and nobody complained. Therefore you are
evidently free to skip what follows'.
The actual definition is the following:

\newcommand\tableofcontents{%
      \if@twocolumn
          @restonecoltrue\onecolumn
      \else
          @restonecolfalse
      \fi
      \chapter*{\contentsname
              @mkboth{%
\MakeUppercase\contentsname}{\MakeUppercase\contentsname}}%
      @starttoc{toc}%
      \if@restonecol\twocolumn\fi
      }

while I suggest it should the following:

\renewcommand\tableofcontents{%
      \if@twocolumn
          @restonecoltrue\onecolumn
      \else
          @restonecolfalse
      \fi
      \chapter*{\contentsname}
              @mkboth{%
\MakeUppercase\contentsname}{\MakeUppercase\contentsname}%
      @starttoc{toc}%
      \if@restonecol\twocolumn\fi
      }

Why? Because in the original definition the \markboth macro is part of
the \chapter* argument and might get expanded at the wrong moment; with
the suggested "correction" it is not a moving argument and does not get
expanded until it is its turn to do so.

The difference is just a closed brace moved from one position to an
earlier one. It is a negligible detail, but it produces a robust
command. Possibly a \protect might do the same job, but displacing a
brace appears to me a simpler solution.

If a change is made, it would be a good idea to control the similar
macros the are contained in the other standard classes.

Of course I might redefine this command whenever I use my files; but it
seems to me that the small change I am suggesting is simple and without
consequences; I might be wrong, since I do not have a full vision over
all packages that might interact with this definition; I do not have the
software and the competence to do this kind of tests.

@FrankMittelbach
Copy link
Member

FrankMittelbach commented Jul 2, 2018 via email

@FrankMittelbach
Copy link
Member

If Claudio can provide an example where this really is a problem, I'm happy to reconsider.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants