\s[] gives syntax error (should restore previous size)

[Jim Avera]

#!/bin/sh
# \s[] causes a syntax error. According to 'info groff'
# \s with no argument should restore the previous point size
# Such behavior would be consistent with \m \f and \F, so this seems
likely to be a bug

# (using groff 1.22.2 build from cvs)

groff -Tps <<'EOF' >/dev/null
.warn
.ps 10
.tm Before: .s=\n[.s]
original size \s[20] larger \s[] previous size
.tm After: .s=\n[.s]
.if !\n[.s]=10 .ab bug .s=\n[.s] -- \\s[] did not restore previous point
size

[Werner LEMBERG]

> # \s[] causes a syntax error. According to 'info groff'
> # \s with no argument should restore the previous point size

Ah, this is badly formulated in the info manual. The groff(7) manpage
documents it correctly.

`\s' *always* needs an numeric argument. So the valid forms to return
to the previous size are

\s0
\s(00
\s[0]
\s'0'

It's the `.ps' request which can be called without an argument.

Fixed in CVS, thanks.


Werner

[Jim Avera]

Thanks for fixing the docs.

I'm curious, though, why \s can not support the no-argument form
in the same way that \f and \F do.

-Jim

[Werner LEMBERG]

> I'm curious, though, why \s can not support the no-argument form in
> the same way that \f and \F do.

Why should it? \s always needs a numerical value, where 0 is a
natural default. On the other hand, \f and \F expect strings, where
the natural default is the empty one.


Werner