blob: ea8b6608c1d236ceed2e0f126f8873d97c3bf6f9 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
|
<head>
<title>UK TeX FAQ -- question label newlineargs</title>
</head><body>
<h3>Start of line goes awry</h3>
<!-- asterisk square bracket start line -->
<p/>This answer concerns two sorts of problems: errors of the form
<blockquote>
<pre>
! Missing number, treated as zero.
<to be read again>
g
<*> [grump]
</pre>
</blockquote><p>
and those where a single asterisk at the start of a line mysteriously
fails to appear in the output.
<p/>Both problems arise because <code>\</code><code>\</code> takes optional arguments. The
command <code>\</code><code>\*</code> means “break the line here, and inhibit page break
following the line break”; the command <code>\</code><code>\[</code><<i>dimen</i>><code>]</code>
means “break the line here and add <<i>dimen</i>> extra vertical space
afterwards”.
<p/>So why does <code>\</code><code>\</code> get confused by these things at the start of a
line? It’s looking for the first non-blank thing, and in the test it
uses ignores the end of the line in your input text.
<p/>The solution is to enclose the stuff at the start of the new line in
braces:
<blockquote>
<pre>
{\ttfamily
/* C-language comment\\
{[grump]} I don't like this format\\
{*}/
}
</pre>
</blockquote><p>
(The above text derives from an actual post to
<i>comp.text.tex</i>; this particular bit of typesetting could
plainly also be done using the <code>verbatim</code> environment.)
<p/>The problem also appears in maths mode, in arrays and so on. In this
case, large-scale bracketing of things is <em>not</em> a good idea; the
TeX primitive <code>\</code><code>relax</code> (which does nothing except to block
searches of this nature) may be used. From another
<i>comp.text.tex</i> example:
<blockquote>
<pre>
\begin{eqnarray}
[a] &=& b \\
\relax[a] &=& b
\end{eqnarray}
</pre>
</blockquote><p>
which is a usage this FAQ would not recommend, anyway: refer
to the <a href="FAQ-eqnarray.html">reason not to use <code>eqnarray</code></a>.
<p/>Note that the <i>amsmath</i> package modifies the behaviour of
<code>\\</code> in maths. With <i>amsmath</i>, the <code>eqnarray</code>
example doesn’t need any special measures.
<p/><p>This question on the Web: <a href="http://www.tex.ac.uk/cgi-bin/texfaq2html?label=newlineargs">http://www.tex.ac.uk/cgi-bin/texfaq2html?label=newlineargs</a>
</body>
|