394

I see that the code in many packages and examples contains percent signs % at the end of (many) lines. What are they used for? Do they affect the parsing of those lines?

6 Answers6

322

The short answer is what others have said, % starts a comment that goes to the end of the line. The normal effect is that it doesn't insert the space (or a \par) from the newline.

The longer answer is that as TeX parses its input, it reads the input file line by line. It strips off tailing whitespace (including any carriage return and newline) and then appends a character corresponding to the number in the \endlinechar register (provided it isn't -1 or greater than 255). By default, the value is 13 which corresponds to an ASCII carriage return. (TeX denotes this by ^^M.) You can change this register to be any value.

Unless the category codes have been changed (e.g., by the \obeylines macro), ^^M has category code 5, or end of line. When TeX reaches an end of line character, it discards the rest of the line and does one of three things: nothing, insert a space token, or insert a \par token, depending on what state TeX was in (S, M, or N, respectively).

So what does this have to do with %? Well, since the comment character causes TeX to ignore the rest of the input line, the end of line character that got appended gets ignored too.

This can frequently be important when playing around with category codes of ^^M (again, using \obeylines or similar).

The long answer is contained in Chapter 8 of The TeXbook.

One final use that no one has mentioned is that it is sometimes necessary for the line to end with a space character and not a end of line character. One example is that a backslash followed by a space is different than a backslash followed by a newline:

\show\ 
\show\ %

In the first line, there's a space following the \, but it'll get stripped off as described so what you get instead \^^M as you can see by what TeX prints out.

> \^^M=macro:
->\ .

That is, \^^M is a macro that expands to a control space: . In the second case, the comment prevents the space from being stripped off and the end of line char is ignored. TeX prints out the following.

> \ =\ .

That is, is a TeX primitive (see control space in either The TeXbook or TeX by Topic).

The usual reason for % is suppressing spaces in macro definitions. Consider the macros \nopercents and \percents below.

\documentclass{minimal}
\newcommand*\bracket[1]{[#1]}%
\newcommand*\nopercents[1]{
    \bracket{#1}
}
\newcommand*\percents[1]{%
    \bracket{#1}%
}
\begin{document}
X\nopercents{blah}X

X\percents{blah}X
\end{document}

Superficially, they appear to do the same thing: pass their input to \bracket. The difference is that the newlines becomes space tokens in \nopercents but are ignored in \percents due to the %. So X\nopercents{blah}X expands to X [blah] X whereas X\percents{blah}X expands to X[blah]X.

Addendum regarding spaces at the beginning of a line.

A % only swallows whatever follows it on a line. It does not have any effect on white spaces that begin the next line. Under most circumstances, spaces at the beginning of a line are ignored by TeX itself. There are a couple of exceptions:

  • When the line is otherwise entirely blank, it is interpreted as a paragraph break.

  • When \obeyspaces is in effect, every space is carried into the output; this is true within verbatim mode and can also be requested explicitly.

If \obeyspaces is in effect while a command or environment is being defined, if the definition occupies more than one line, any spaces at the beginning of a continuation line will be preserved in the definition. Indentation is often used in defining commands or environments to make the code easier to understand (usually a good thing), but while \obeyspaces is in effect, this has an unwelcome result and should be avoided. \obeyspaces should normally be used only within a delimited scope ({ } or \begingroup ... \endgroup) to avoid unwanted results.

TH.
  • 62,639
  • I thought that a percent sign also swallows all initial whitespace from the next line? 2. When writing macros, in which situations would one (broadly speaking) want to end lines with a percent sign? (I know someone might be tempted to answer "whenever you don't want a whitespace there", but I'm hoping for a list or a pointer to a list of common pitfalls and traps.)
  • – Lover of Structure Sep 12 '12 at 18:56
  • 10
    @user14996 -- a % only swallows the end-of-line character. tex itself in most cases is what swallows (rather ignores) spaces at the beginning of a line; it's possible to turn this off, with, e.g., \obeyspaces, and this is very useful when quoting blocks of code, to preserve meaningful indentation. – barbara beeton Sep 28 '12 at 18:40
  • @barbarabeeton Thanks for this piece of info, because for a long time I have believed otherwise, possibly because of the following statement on Wikibooks: "When LaTeX encounters a % character while processing an input file, it ignores the rest of the current line, the line break, and all whitespace at the beginning of the next line." (emph. added) As I am not an expert, I won't correct this, but perhaps one of you might clarify the intricacies of this either there or (better) here? (And, did you mean \obeywhitespace?) – Lover of Structure Sep 29 '12 at 16:30
  • @barbarabeeton See also the "Comments" section here. – Lover of Structure Sep 29 '12 at 16:36
  • 8
    @user14996 -- it's true that a % causes (la)tex to ignore whatever comes after on that line, including, of course, the line break. but it's tex itself that ignores spaces at the beginning of a line, and a totally blank line (no % allowed, so that the line break can be seen) will be recognized as a paragraph break, equivalent to \par. the sources you cite are mistaken. and regarding \obeyspaces, that's defined in plain.tex and in the texbook, p.352. i'm not familiar with \obeywhitespace, and don't find it in my trusted collection of reference books. – barbara beeton Sep 29 '12 at 19:06
  • @barbarabeeton Are there any scenarios where I shouldn't use line-initial whitespace? – Lover of Structure Oct 06 '12 at 22:20
  • 2
    @user14996 -- line-initial whitespace is preserved by (la)tex within most "verbatim" environments. when a new command is being defined within such an environment, spaces must not be input at the beginnings of lines to make the definition easier for someone to read (usually a polite thing to do, as well as being helpful when one has to diagnose problems); such spaces will be carried into the output. – barbara beeton Oct 07 '12 at 11:22
  • @barbarabeeton Can you give 1 or 2 examples of when something is defined "within a 'verbatim' environment"? – Lover of Structure Oct 07 '12 at 17:56
  • @user14996 -- these two files (in tex live or ctan) have such definitions: eplain.tex starting with the line \gdef\obeywhitespace{%, and tugboat.sty in the section % Definitions of spaces and ^^M. there's also a block in latex.ltx just after the line \message{verbatim,}. this code is rather arcane, but if there were spaces at the beginnings of the affected lines, it would wreak havoc. – barbara beeton Oct 08 '12 at 13:59
  • @barbarabeeton Many thanks for your examples. So I think that in nearly all "user" contexts of LaTeX including those of the user occasionally defining his own commands and doing macro tricks, line-initial whitespace can be liberally used. Please contradict me if this is not correct. – Lover of Structure Oct 08 '12 at 23:08
  • 3
    @user14996 -- most "ordinary" users should feel free to use line-initial whitespace to make input easier to comprehend. the only time it's really necessary to "be careful" is in verbatim-type environments, especially when defining commands to be used in such environments. with this one important exception, line-initial whatespace, used consistently, is generally a good thing. – barbara beeton Oct 09 '12 at 17:46
  • so is it considdered a good practice to add % after each line (when/where possible) in a macro/class definition? – Pieter Stroobants Nov 11 '14 at 04:47
  • 3
    @PieterStroobants If the line ends with a control word (a control sequence consisting of catcode 11 characters)—but not a control word (a control sequence consisting of 1 character with catcode different from 11) nor a control space—spaces are ignored so there's no need for %. If the line ends with another token, the end of line will become a space. If you don't want the space, use %. Sometimes you want the space, e.g., after number or glue specifications: \count@=37 you wouldn't use % so TeX inserts the space and thus ends the number. See TeXbyTopic, section 2.10.2 for details. – TH. May 11 '16 at 20:12
  • @TH. -- there are a couple of new comments on the answer by Kit, below, that make me think it might be useful to add an addendum to your answer regarding spaces at the beginning of a line. i'd be happy to condense my comments here into such an addendum, but don't want to do that without your permission. – barbara beeton May 21 '17 at 20:48
  • This answer gives a nice description of how the parser treats %. But as for why you would do it, this answer only mentions that it's useful (1) when playing around with category codes of ^^M, and (2) when you need your line to end with a space. Since neither of these is usually the case, how do you explain the rampant usage of %? Surely it has to do with the annoying too-much-space-in-the-document phenomenon when a % is "forgotten" in a macro -- could this please be explained? Specifically, why is a newline from inside a macro any different from a newline next to where the macro is used? – Matt May 21 '17 at 23:08
  • @barbarabeeton, By all means! – TH. May 22 '17 at 01:54
  • @Matt, I guess the second sentence hints at it, "The normal effect is that it doesn't insert the space…" Maybe I can make that more explicit. – TH. May 22 '17 at 01:54
  • @TH: That does not explain the standard confusion that people have about this. A macro is expected to simply substitute its contents into the place where it is used. So if a macro contains some whitespace, then that whitespace would get "plugged into" the text where the macro was used. But extra spaces and newlines are no problem in the text! (Although a double newline would start a paragraph.) So why is it a problem when extra spaces and/or newlines come from a macro? Why do we see extra-wide spaces between words in that case? – Matt May 22 '17 at 10:14
  • @Matt, I'm not sure I follow. Macro expansion replaces the macro token (and any argument tokens) with the replacement tokens (it gets called the replacement text, but it's really tokens because it has already been tokenized). It's not a textual replacement, but TeX's parsing rules don't change. Maybe you're thinking of something like vertical mode where space tokens and \par commands are ignored. For macros designed to be used in vertical mode, extra spaces in the macro definitions waste memory but are otherwise harmless. – TH. May 22 '17 at 16:18
  • @Matt, maybe this? \def\foo#1{ #1 } Then, X \foo{bar} X expands to X bar X (with four space tokens) whereas had I written X bar X (with four space characters), TeX would produce X bar X (with two space tokens). The difference comes from when the replacement text of \foo is tokenized, it contains a leading and trailing space token. So X \foo{bar} X yields an X token, a space token, \foo{bar} is expanded to a space token, bar, and another space token. Then, there's a space token and the final X token. https://texhacks.blogspot.com/2009/10/spaces-in-tex.html may help. – TH. May 22 '17 at 16:30
  • StackExchange ate my extra spaces. Everywhere I wrote (with four space characters) should really have two sets of double spaces. – TH. May 22 '17 at 16:32
  • @TH: Yes, your comments here are exactly on target. I love your new section, "The usual reason for %..." And the main reason you need to use them, if I understand you, is that whitespace regions in the source are only reduced to a single space before macro substitutions are done. (I'm sure this is so obvious to you that it needs no mention, but it is not obvious before you learn it!) So actually I would update your new section to use the four-space-character example as in your comment, since I think that illustrates this issue nicely. – Matt May 23 '17 at 12:27
  • Soome nitpicking: Afaik \endlinechar is not a register but an . – Ulrich Diez Jun 28 '22 at 17:07