[latexrefman-discuss] *The* solution is to type @code{@{@}} after the command and before the space.

[Vincent Belaïche]

Answers below,

Le 31/01/2016 11:49, Johannes Böttcher a écrit :
> David Carlisle once wrote:
> > xspace was a silly idea. [1]
>
> An answer of David concerning the drawbacks of xspace [2] ends with:
> > So, if you find it useful, fine, it's there. But personally I wouldn't recommend it.
>
>
> Based on that and the fact, that it is not part of the base core, i would omit mentioning it in the ref manual.
>
>
> [1] http://chat.stackexchange.com/transcript/41?m=9404871#9404871
> [2] http://tex.stackexchange.com/questions/86565/drawbacks-of-xspace/86620#86620
>
>

I am not strongly opinionated about this. Personnally I don't use
xspace, and I share the arguments given in the discussions which you
refer to.

I know that xspace is used by frenchb, so that when xspace package is
loaded before [frenchb]babel then \fg (ie « Fermez les Guillemets », aka
`»' ) is xspaced. I also know that some people like to xspace that kind
of macros refering to a single character. I don't think that xspace is
good for beginners, although the original idea behind it was that.

So, I don't mind if the paragraph about xspace is removed altogether
from the manual.

I think that anyway we need some addition to the manual about spaces,
because, AFAIK, nothing is said about EOL being spaces, and line leading
spaces being ignored. Maybe xspace stuff would be better pushed into a
node about "Gory details about space gobbling after control words",
because the xspace thing is not the only funny thing: some commands
(like those of some older version of fmtcount) that take a mandatory
argument followed by an optional argument in the *last* place, will also
gobble space, even though after the closing `}'. All of this is package
related, and not the standard behaviour, but that may be worth shortly
mentioning that the rule about space gobbling is not so absolute.


To Karl: after a review of your edit, I realize that it has an error,
and so has what I had edited in node

   (info "(LaTeX2e-fr) \(SPACE) after CS")

You wrote:


   @TeX{} ignores spaces in the source following a command (or any
   control sequence), as in @samp{\cmd }.

but this is not strictly speaking true, control sequence fall into two
categories:

- control words, ie escape char followed by a sequence of one or more
  letters, and

- control symbols, ie espace char followed by a an `other'.

Only control words gobble the following spaces, control symbols
don't. So node

   (info "(LaTeX2e-fr) \(SPACE) after CS")

should be renamed with CS -> CW both in node name & title, and probably
we should also add somewhere a definition of control sequence, control
word, control symbol, command, macro, token, and so on.

To my understanding "command" stritly speaking means the object that can
be referred to by a control sequence, and that is why, loosely speaking,
we often say that a control sequence "is a command". So if \foo is
undefined, it is not a command (ie it does not refer to any command),
and if we \let\foo\bar, then \foo and \bar are the same command (ie
refer to the same command object).

This is why strictly speaking we cannot say that "spaces following a
command are gobbled", it would be more correct to say that "spaces
following a control name are gobbled". A command is not a token in the
input stream, rather it is object that is inferred from a token.

Macros are special cases of commands that expand to strings of tokens.

In the same vein, we cannot say that a blank empty line calls the same
command as the \par control sequence, rather when a blank empty line (or
a vertical command in horizontal mode) is met, then the input processor
inserts a \par token in the input, so a blank empty line would be better
described as a macro expanding to \par, which in turn, by its primitive
definition, refers to the paragraph command, than as also refering to
the paragraph command. That is why to play tricks with paragraph we just
need to redefine \par.

Well, slightly drifting away from the initial topic...

   Vincent.

>
>
>
> On 01/31/2016 12:21 AM, Karl Berry wrote:
>>      Well, this is not *The* solution,
>>
>> Certainly true.
>>