groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: groff man(7) `B` macro behavior with `\c`, and input traps


From: G. Branden Robinson
Subject: Re: groff man(7) `B` macro behavior with `\c`, and input traps
Date: Fri, 10 Jun 2022 07:35:34 -0500

At 2022-06-06T21:14:01+1000, John Gardner wrote:
> I haven't read the entirety of this thread, but why hasn't the name
> *"command suppressor"* or *"control suppressor"* been considered?
> AFAIK, \& has no other uses outside of an input line (diversions
> notwithstanding), so naming it *"input break"* is confusing at best.

It is idiomatically used for several purposes.

1. Getting control characters away from the beginning of an input line
   so they won't be interpreted as such.
2. Cancelling end-of-sentence detection without putting a glyph or
   motion on the output.
3. Preventing kerning adjustments from being applied to a glyph pair.
4. Marking empty tbl(1) entries.

There are other applications, but those are the ones I can think of
immediately.

> Last year I was confused as to why this wasn't working:
> 
> .di FOO
> \&.BAR
> .br
> .di
> .if '\*[FOO]'.BAR' …
> 
> ... and it eventually dawned on me that \& was preserved in the
> diversion, as opposed to discarded after evaluation. Had the sequence
> been named *"input break"* in the documentation, the thought of \&
> being an opaque character might never have occurred to me.

In groff, \& becomes a "dummy token" internally and this is one respect
in which thinking of it as a "dummy character" is helpful.

And, yes, that's a good argument against "input break" that had not
occurred to me when I changed the thing's name in our documentation.
The contents of a diversion are no longer input, but something else.

Regards,
Branden

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]