I'm certain I have read that xspace can cause more problems than it solves. But I cannot find anything to that effect either on this site or the web. Are there any drawbacks or risks associated with it?
2 Answers
I originally implemented xspace a long time ago (for LaTeX 2.09) as, like most LaTeX beginners, I'd had a document where I had omitted a {} or \ and so had a missing space in the final document.
The original version used a very simple nested test for following punctuation, but it could get the test wrong in some (well rather a lot really) of cases. Morten made the tests a lot better so the current version makes the correct choice in more cases and is more easily customised, however making the tests more complicated highlights the problem with this kind of package.
The rule in TeX is really quite simple, after a command name that uses letters (as opposed to single character command names using non-letters such as \$) white space is ignored.
It is easy to forget to use \ or {} but the result of forgetting is very predictable, you lose white space in the result. Conversely with xspace the macro will get the correct space most of the time, but it isn't easy to predict when it will get it wrong, and so it's much harder to learn to enter the markup in a way that is always correct rather than having to always visually check for missing space, which rather negates the purpose of the command.
So, if you find it useful, fine, it's there. But personally I wouldn't recommend it.
answered Dec 11, 2012 at 22:47
-
136
-
3Are there any examples of erratic
xspacebehaviour? Such “wrong” cases are described neither in thexspacemanual nor above. Could you post an example ofxspacegetting things wrong, please? Feb 1, 2016 at 9:44 -
2The answer in tex.stackexchange.com/a/15254/19642 is a rather obvious problem that is solved via adding an exception. Is there an example where
xspace's incorrect spacing cannot be corrected using the package’s own capabilities? Feb 1, 2016 at 9:53 -
4@AndreïKostyrka oh basically it will always be possible to follow
\xspaceby a command that is sufficiently complicated that xspace can not work out if it will produce a space or not, you could make it call pgfmath rand and randomly add space for example but there are probably less silly examples. But even sensible examples if you need to check the output and then extend xspace's exception list it is probably safer just to always use\to get the space when needed. Feb 1, 2016 at 10:33 -
6Surprisingly,
\xspacefails when followed by another\xspace. So if you combine nested commands that use\xspace, you'll get excessive spaces.– giustiFeb 9, 2017 at 16:46
It has been mentioned on the site before, however, it seems to me that it can have its place here. You can define your commands in such a way that you can't forget the space at all. This is done by defining:
\def\ES/{Einstein}
(you can't use \newcommand for this). This way, the proper syntax in-document is
The physisist \ES/ proved the so-called \ES/'s theorem.
You can test yourself that the space in \ES/ proved does not get eaten, because in real, the trailing / is not part of the name of the macro, but rather a sort-of "obligatory fixed-valued argument", that is called macro delimiter in TeX's jargon. If you omit this / and try to write \ES proved, you get a not-so-cryptic error message
Use of \ES doesn't match its definition
which means exactly what it says: You defined \ES it to be followed by / and this is missing.
However, the best thing to do is not to define shorthands like \ES for Einstein. Then you don't need xspace and you can't reach any such problems.
-
26The Shorthand for Einstein is maybe superfluous but there are many cases where a shortcut comes in handy. E.g. if you want to format the name of something always in sans you should define a shortcut for
\textsf{somename}. If your publisher then thinks that sans is bad simply change the definition instead of search for all occurrences. Furthermore defining such shortcuts ensures a consistent layout and fits (in my eyes) perfectly in the principles of logical markup …– TobiNov 26, 2013 at 14:29 -
1@Tobi Then, I would go with
\N{Einstein}or a similar short-named command.– yo'Nov 26, 2013 at 18:09 -
2“… they are exceptional” depends on how you work and what you work on – I guess ;-) … I wasn’t aware of the
xspacediscussion yet, but I consider removing the\xspace:-)– TobiNov 26, 2013 at 19:01 -
1@Tobi: If you already mention... How
\LateXis handling the issue? It seems like both\TeXand\LaTeXuses\@at the end. Is this what takes care of the problem of space after the macro?– DrorMar 26, 2014 at 9:47 -
2@yo' The
\@in\TeXis needed to get an end-of sentence space in\TeX.Feb 9, 2017 at 16:51
\newcommand{\test}{\emph{test}\xspace}and still the problem exists: the italic correction is inserted in situations such as\test,, which is wrong. I never recommend (nor use myself)xspace. :)\test{}if a space follows. That's all.\xspace. Once you get used to it, ending macros with a{}is not so big a deal. Note there is also a solution by Will Robertson that relies on using explicitly 'delimited' macros that will cause an error if you don't end them properly (e.g.,\def\foo/{\emph{foo}}-- must be written as\foo/). I could never get used to doing it, but it may work better for you.\newcommand{\newentity}[3][/]{\@ifdefinable{#2}{\def#2#1{#3}}}and then\newentity{\foo}{\emph{foo}}will define\footo require/after it; or\newentity[|]{\bar}{\textbf{bar}}would require\bar|. As usual\makeatletterand\makeatotherare necessary around the definition of\newentity;\newentitywill throw an error if the command is already defined.