Re: .bp not working in groff 1.23.0 when it worked fine in 1.22.4

[G. Branden Robinson]

At 2024-01-23T22:13:26-0600, Dave Kemper wrote:
> On 1/23/24, G. Branden Robinson <g.branden.robinson@gmail.com> wrote:
> > At 2024-01-23T20:52:34-0600, Dave Kemper wrote:
> >> However, .bp arguably shouldn't have been affected by the change,
> >> since it probably wasn't subject to the same historical ambiguity.
> >
> > I agree, and I wasn't happy about it.
> 
> I wonder if the proper way to address this lies in core groff.
> 
> Having no-space mode suppress .bp seems quirky, and at odds with the
> info manual's stated use case for the mode: "A paragraphing macro
> might ordinarily insert vertical space to separate paragraphs.  A
> section heading macro could invoke 'ns' to suppress this spacing for
> the first paragraph in a section."  (CSTR #54, befitting its terser
> nature, suggests no usage for .ns.)  But of course this behavior
> cannot be overturned unilaterally.
> 
> However, .ns currently takes no arguments -- but it could, a value to
> specify "suppress only vertical space, but not page breaks."  The
> behavior with no argument would be unchanged, so historical usage
> would work as it always has.
> 
> There are probably down sides to this I haven't thought of.

I wonder the same thing.  Similar extensions to specific AT&T request
syntax have occurred to me before as well, but every time I've looked
into the issue, I've noticed something...

As far as I know, groff has never extended AT&T troff syntax in _this_
respect.

The argument count to requests (unlike macros) is seemingly sacrosanct.

I'm unaware of any explicit exhortation against doing this, but having
seen AT&T-descended troff source and GNU troff's own, I'm going to
venture a guess that the manually-constructed recursive descent parsers
that both use make this a dangerous frontier to cross.  If the
formatter's grammar had been expressed formally, say with Yacc, it might
be a different story.  But there is no general request argument parser.
When the formatter decided it has seen a request, it hands control off
to a function which has total discretion to do whatever it wants with
the input stream; the parser's input reader is global state, no less.

The problem here isn't that we can't do this in GNU troff; the problem
is that if another formatter is given input for GNU troff that exercises
such an extension, the result may be worse than simply not supporting
the extension, or snarling an error message, or ignoring input until the
next line--we might instead kick that formatter into an undefined state.

One of my first lessons in this area was discovering that I had to call
`skip_line()` at the end of the logic implementing every GNU troff
request.  What this does is eat up white space and comments and position
the input cursor at the start of the next input line.[1]  In other
parsers, a command handler might be handed "a line" or an argument list.
In troff, you get the original input stream.  The world is yours.

So I'm uneasy with solving the problem this way because the language is
so ill-defined in this respect.

Because macro calls are interpreted in a general manner, they don't have
this problem.  But a macro can't solve this problem in the formatter.

Regards,
Branden

[1] _If_ you could count on every *roff to do the equivalent of
    `skip_line()` in _every_ request handler, then my concern is
    misplaced.  Personally, I don't trust C programmers anywhere near
    enough to rely on such an assumption.

signature.asc
Description: PGP signature