When TeX is laying out text, it doesn't work from word to word, or from line to line; the smallest complete unit it formats is the paragraph. The paragraph is laid down in a buffer, as it appears, and isn't touched further until the end-paragraph marker is processed. It's at this point that the paragraph parameters have effect; and it's because of this sequence that one often makes mistakes that lead to the paragraph parameters not doing what one would have hoped (or expected).
Consider the following sequence of LaTeX:
{\raggedright % declaration for ragged text
Here's text to be ranged left in our output,
but it's the only such paragraph, so we now
end the group.}
Here's more that needn't be ragged...
TeX will open a group, and set the ragged-setting parameters within
that group; it will then save a couple of sentences of text and
close the group (thus restoring the previous value of the
ragged-setting parameters). Then it encounters a blank line, which it
knows to treat as a \par token, so it typesets the two sentences;
but because the enclosing group has now been closed, the parameter
settings have been lost, and the paragraph will be typeset normally.
The solution is simple: close the paragraph inside the group, so that the setting parameters remain in place. An appropriate way of doing that is to replace the last three lines above with:
end the group.\par} Here's more that needn't be ragged...
In this way, the paragraph is completed while the setting parameters are still in force within the enclosing group.
Another alternative is to define an environment that does the appropriate job for you. For the above example, LaTeX already defines an appropriate one:
\begin{flushleft}
Here's text to be ranged left...
\end{flushleft}
Sometimes LaTeX saves data it will reread later. These data are often the argument of some command; they are the so-called moving arguments. (`Moving' because data are moved around.) Places to look for are all arguments that may go into table of contents, list of figures, etc.; namely, data that are written to an auxiliary file and read in later. Other places are those data that might appear in head- or footlines. Section headers and figure captions are the most prominent examples; there's a complete list in Lamport's book (see TeX-related books).
What's going on really, behind the scenes? The commands in the moving
arguments are already expanded to their internal structure during the
process of saving. Sometimes this expansion results in invalid TeX
code when processed again. ``\protect\cmd'' tells LaTeX to save
\cmd as \cmd, without expansion.
What is a `fragile command'? It's a command that expands into illegal TeX code during the save process.
What is a `robust command'? It's a command that expands into legal TeX code during the save process.
No-one (of course) likes this situation; the LaTeX3 team have removed the need for protection of some things in the production of LaTeX2e, but the techniques available to them within current LaTeX mean that this is an expensive exercise. It remains a long-term aim of the team to remove all need for these things.
\verb work within...?
The LaTeX verbatim commands work by changing category codes. Knuth
says of this sort of thing ``Some care is needed to get the timing
right...'', since once the category code has been assigned to a
character, it doesn't change. So \verb has to assume that it is
getting the first look at its parameter text; if it isn't, TeX has
already assigned category codes so that \verb doesn't have a
chance. For example:
\verb+\error+
will work (typesetting `\error'), but
\newcommand{\unbrace}[1]{#1}
\unbrace{\verb+\error+}
will not (it will attempt to execute \error).
This is why the LaTeX book insists that verbatim
commands must not appear in the argument of any other command; they
aren't just fragile, they're quite unusable in any command parameter,
regardless of
\protection.
TeX provides two primitive commands \uppercase and
\lowercase to change the case of text; they're not much used, but
are capable creating confusion.
The two commands do not expand the text that is their parameter -
the result of \uppercase{abc} is `ABC', but \uppercase{\abc}
is always `\abc', whatever the meaning of \abc. The commands
are simply interpreting a table of equivalences between upper- and
lowercase characters.
They have (for example) no mathematical sense, and
\uppercase{About $y=f(x)$}
will produce
ABOUT $Y=F(X)$
which is probably not what is wanted.
In addition, \uppercase and \lowercase do not deal very well
with non-American characters, for example \uppercase{\ae} is the
same as \ae.
LaTeX provides commands \MakeUppercase and \MakeLowercase
which fixes the latter problem. These commands are used in the
standard classes to produce upper case running heads for chapters
and sections.
Unfortunately \MakeUppercase and \MakeLowercase do not solve
the other problems with \uppercase, so for example a section
title containing \begin{tabular} ... \end{tabular} will
produce a running head containing \begin{TABULAR}. The simplest
solution to this problem is using a user-defined command, for
example:
\newcommand{\mytable}{\begin{tabular}...
\end{tabular}}
\section{A section title \protect\mytable{}
with a table}
Note that \mytable has to be protected, otherwise it will be
expanded and made upper case.
# signs doubled in macros?
The way to think of this is that ## gets replaced by # in just the
same way that #1 gets replaced by `whatever is the first argument'.
So if you define a macro and use it as:
\def\a#1{...#1...#1...#1...} \a{b}
the macro expansion produces `...b...b...b...', which people find normal. However, if we now fill in the `...':
\def\a#1{---#1---\def\x #1{xxx#1}}
\a{b} will expand to `---b---\def\x b{xxxb}'. This
defines \x to be a macro delimited by b, and taking no
arguments, which people may find strange, even though it is just a
specialisation of the example above. If you want \a to
define \x to be a macro with one argument, you need to write:
\def\a#1{---#1---\def\x ##1{xxx##1}}
and \a{b} will expand to
`---b---\def\x #1{xxx#1}', because #1 gets replaced by `b'
and ## gets replaced by #.
To nest a definition inside a definition inside a definition then
you need ####1, as at each stage ## is replaced by
#. At the next level you need 8 #s each time, and so on.