16

Do starred commands eat up spaces after them, like unstarred ones do? That is, is \somecommand* nextword equivalent to \somecommand*nextword?

And: Does it depend on the particular way a starred command is defined?

Edit: Note that the original version of my question left out me considering only zero-argument commands. I was assuming this, and it was mostly clear (albeit implicit) from the question statement. User @tohecz has written a valuable answer (to the pre-edit version) addressing this detail.

Note that I'm asking about commands with a star at the end of their name (\somecommand*), not about whether the command was defined using a starred defining command (e.g. with \newcommand*).

Community
  • 1
Lover of Structure
  • 22,025
  • This should be fairly easy to test or am I missing something? Behavior really should be the same as without the *, unless the macro was designed to do things differently based on the presence or absence of the *. – Peter Grill Feb 11 '13 at 05:07
  • @PeterGrill Yeah :-) I was gonna test it but then found that there are a handful of different ways of doing things (e.g. what's in the UK TeX FAQ). I figured someone might already know this already, if the answer is method-independent (for the methods that are presently used). – Lover of Structure Feb 11 '13 at 05:12

4 Answers4

17

No they don't:

enter image description here

\documentclass{article}
\usepackage{suffix,xparse}% http://ctan.org/pkg/{suffix,xparse}
\makeatletter
\newcommand{\mycmdA}{\@ifstar
  \mycmdA@star% \mycmd*
  \mycmdA@nostar% \mycmd
}
\newcommand{\mycmdA@star}{A1}
\newcommand{\mycmdA@nostar}{A2}
\NewDocumentCommand{\mycmdB}{s}{%
  B\IfBooleanTF{#1}{1}{2}}
\newcommand{\mycmdC}{C1}
\WithSuffix\newcommand\mycmdC*{C2}
\makeatother
\begin{document}
Here is \mycmdA and \mycmdA* in one line. \par
Here is \mycmdB and \mycmdB* in one line. \par
Here is \mycmdC and \mycmdC* in one line.
\end{document}
mafp
  • 19,096
Werner
  • 603,163
11

As the other answers show, they do not. However, the spaces get "eaten" if the macro takes other arguments after *:

\documentclass{article}

\pagestyle{empty}

\begin{document}

\section {Hello}
\section* {World!}

\end{document}

enter image description here

In general, TeX ignores all spaces when looking for an argument (unless it is not, which is when an argument is delimited (like optional arguments are):

\newcommand{\foo}[1][A]{(#1)}
\foo [abc]    % prints: (abc)
\foo[abc]     % prints: (abc)
\foo [ abc]   % prints: ( abc)
\foo[ abc]    % prints: ( abc)

\def\baz|#1|{(#1)}
\baz |abc|    % prints: (abc)
\baz|abc|     % prints: (abc)
\baz | abc|   % prints: ( abc)
\baz| abc|    % prints: ( abc)
yo'
  • 51,322
  • Good point; see my edit to the question statement. – Lover of Structure Feb 11 '13 at 07:52
  • @LoverofStructure Despite not being what you ask for, it seems to be a consensus here that we treat even the closely-related stuff, in the sense of "wiki-like" approach ;) – yo' Feb 11 '13 at 07:59
  • I welcome your answer and I think it belongs here. (Just like other informative edits and questions, though some other SE sites have a more rigid approach towards the latter.) But it's also good that I clarified the scope of my question; it'll prevent confusion. More importantly I'd find it weird not to tell you about my edit :-) – Lover of Structure Feb 11 '13 at 08:12
  • Agreed :) . – yo' Feb 11 '13 at 09:02
  • Ha, I've discovered unexpected behavior!! Check out the following: \mycmdA *, \mycmdB *, \mycmdC *. (To actually print a star, the following works: \mycmdA **, \mycmdB **, \mycmdC **.) Is this intentional? – Lover of Structure Feb 11 '13 at 19:53
  • Oh, my previous comment actually applies to the Werner thread. Let me tell him. – Lover of Structure Feb 12 '13 at 00:57
  • 1
    @LoverofStructure: This is intentional. All spaces after a control sequence is gobbled; grabbing the first * is as a result of \@ifstar, leaving a final * for printing... – Werner Feb 14 '13 at 01:46
  • @Werner Good to know, but is this clearly documented for the average user/learner? This is very unexpected given that from a LaTeX perspective we think of the starred version as a single command. In all cases where I'd encounter something like \somecommand * I'd assume that someone is trying to apply \somecommand to the single-token argument *. – Lover of Structure Feb 14 '13 at 05:31
  • @LoverofStructure: Perhaps in a similar context you might find it unexpected that \mycmd{text} yields text if \newcommand{\mycmd}{\textbf}, even though \mycmd doesn't take any argument... – Werner Feb 14 '13 at 05:48
  • @Werner \textbf does take an argument, it's just that this fact is obscured through/in LaTeX's definition mechanism. – Lover of Structure Feb 14 '13 at 12:07
  • @Werner My point is different: We never see a starred command written like this: \somecommand *, but always like this: \somecommand*. An ordinary user of LaTeX would assume that this is "one command", but in fact it's parsed as a control sequence plus a token. And "commands" never have spaces in them (we think). I hope that it's clear that from a parsing grammar or compiler writer's perspective this doesn't look like good design. And if I hadn't tried it out here, I'd still not know. Perhaps I'm using "command" wrong as a LaTeX-technical term, but that doesn't change my point. – Lover of Structure Feb 14 '13 at 12:10
  • @LoverofStructure The other option would have been to make * a letter, but then I don't want to see people complaining about \alpha*\beta not working. As well notice that you can't write \begin{align *} – yo' Feb 14 '13 at 12:49
  • @tohecz About your last sentence: That's good, but it confirms the lack of internal syntactic consistency. About your first sentence: (1) The other option would have been to pick a different character for inclusion in command names. It's limiting already that control sequences can be only letters. (2) Or (simpler) would be to require people writing \alpha * \beta. (3) \somecommand*\beta is already a problem if \somecommand accepts a starred variant and semantically produces some symbol meant to be multiplied to something else (unless you blame the person who wrote that definition). – Lover of Structure Feb 15 '13 at 00:39
  • @LoverofStructure (1) It's much easier to remember that * is the modifier that works in many different situtations. (2) It makes more sense for the macro designers. (3) So \alpha+\beta would work but \alpha*\beta would not? (4) Vast majority of macros taking * take another argument as well, and it very rarely is *. – yo' Feb 15 '13 at 12:29
  • @tohecz (1), (2), and (4) are not reasons against a design where control sequences don't eat spaces. So many programming languages use obligatory () for single-argument functions; the (La)TeX equivalent would be {} for single-argument macros. / An alternative would be to terminate a macro-argument sequence with . or ;. / @(3): Every programming language has token sequences that must be circumvented, for example * immediately before a variable name in C (dereferencing). Usually certain token sequences must be avoided; it's weird that a space inside a command name is permissible. – Lover of Structure Feb 16 '13 at 04:40
  • The problem is that they are not inside a name of a command. The star is not part of the name, it is an optional first argument. Notice that TeX is an expansions language (by design), which means that a "function" with 2 arguments can be actually designed as a "function" with one argument that outputs in the stream another "function" with one argument. And since * is an argument, why whould it eat spaces? The general problem is that TeX is a typesetting system, so spaces have to be "active" in the sense that they do something more than e.g. in C. – yo' Feb 16 '13 at 09:15
  • @tohecz You're are presenting an "argument by legacy constraint"; surely this is more of a "late justification" than a design argument. That * should be regarded an optional argument is a useful point of view, but it's not documented well. Whether the design of TeX is modern is an argument for another discussion, but there is no reason to justify the way space characters are presently handled if it has intransparent syntactic consequences. It's better to leave the warning as is, for people to notice and be cautioned, than to defend the status quo as some sort of obvious and natural choice. – Lover of Structure Feb 17 '13 at 06:15
  • @LoverofStructure Many things are not obvious and natural, in any programming language. Sorry if I present "bad arguments", I'm not a professional "arguer". However, I know many people complaining about different things and having different difficulties in LaTeX, but space between a macro name and the following * has never been one of them. – yo' Feb 17 '13 at 08:23
  • @tohecz Many of your points are good ones, and all of your input is valued anyways :-) I think it's good for our exchange to be here; it'll serve as good information and documentation for other users. – Lover of Structure Feb 18 '13 at 11:26
10

As other answers have indicated, technically the space dropping is part of the scanning for a command name, and at the primitive TeX level the * is not part of the name.

However in LaTeX syntax the star form is always considered a distinct command \section and \section* are documented as two related commands, not one command that looks ahead to see if there is a * or not.

So it is good practice to make the star form have similar behaviour to the non-star form.

In all cases in the base LaTeX format, as far as I can see, the *-command is always used with arguments (like \section*) and so any space is skipped at a different stage or occurs at places where a space character will make a space token but won't produce space in the output \\*, \ProcessOptions*.

Thus I don't think any standard LaTeX * form of a command would produce white space from a space character after the *.

Lover of Structure
  • 22,025
David Carlisle
  • 757,742
  • Or \tableofcontents* in memoir. – egreg Feb 11 '13 at 17:28
  • Thanks! One thing I can't quite follow is the part of the sentence that reads "skipped at a different stage". – Lover of Structure Feb 11 '13 at 19:38
  • @egreg See my comment to the @tohecz thread. David Carlisle's point that in TeX the * is not part of the name shows in those examples. Parsing irregularities in (La)TeX are imho an area that needs improvement. (LaTeX 3?) – Lover of Structure Feb 11 '13 at 19:56
  • 3
    @LoverofStructure in \section {hello} the space is never tokenized it is lost while scanning the command name. in \section* {hello} the space is seen and tokenized but space tokens before mandatory arguments are dropped while scanning for macro arguments "a different stage" – David Carlisle Feb 11 '13 at 20:24
5

Only control words eat space after them! Control words are macros begin with the escape character \ and followed by one or more letters.

kiss my armpit
  • 36,086