Re: [Groff] surprise, surprise

[Clarke Echols]

Ralph Corderoy wrote:
> (I'm replying to several messages in one go here.)
> 
> Having looked into it I'm convinced that allowing . or ' commands to
> be preceded by \ commands is intended and documented.
> 

<snip>

> The November 1992 troff's User's Manual has been quoted several times
> but the second paragraph hasn't.  Here's both.
> 
>     1.1. Form of input. Input consists of text lines, which are
>     destined to be printed, interspersed with control lines, which set
>     parameters or otherwise control subsequent processing. Control
>     lines begin with a control character-normally . (period) or '
>     (single quote)-followed by a one or two character name that speci-
>     fies a basic request or the substitution of a user-defined macro in
>     place of the control line. The control character ' suppresses the
>     break function-the forced output of a partially filled line-caused
>     by certain requests. The control character may be separated from
>     the request/macro name by white space (spaces and/or tabs) for
>     aesthetic reasons. Names should be followed by either space or
>     newline. Control lines with unrecognized names are ignored.
> 
>     Various special functions may be introduced anywhere in the input
>     by means of an escape character, normally \. For example, the
...

<snip>

> In summing up what you appeared to be arguing, Unix troff always allows
> \ commands before . or ' on a line, the User's Manual can be
> interpreted to match, and the structure of the source also backs up
> that it's an intentional feature.  All that's left is to make groff
> work correctly.
> 
> Does this sound like a strong argument?

And some wonder why the majority of users find computer manuals difficult
or useless! :-)  Unix is the bane of anyone looking for straight-forward
logic without the twists of a perverted mind...

Given the passages cited, I'll surrender to the great minds of AT&T (after
all, they were "the right answer", weren't they?) and allow that the
behavior is technically correct, though I find it lacking from a
good-usability/design design perspective.  It is unfortunate that so much
of Unix documentation must describe software behavior, rather than how to
use it successfully.  No wonder Microsquish Word is so popular among the
unwashed masses.

But this entire scenario really demonstrates the necessity of clear,
unambiguous coding in source-file text.  It is always safest to carefully
construct input so that there is no possible means for falsely
interpreting the intended handling of the text.  Thus, I'd never find
myself allowing a line of the form "\fB.tx\fP" to form a line by itself.

I much prefer the use of macros anyway, as in ".B .tx" on a line instead.
No ambiguity.  No possibility of misinterpretation.

Clarke